Cleanup #61160
openUse 64-bit timestamps for the Y2K38 problem
0%
Description
There are multiple places where we store timestamps in 32 bit types. These values will eventually overflow when time for a date on or after the year 2038 is stored (https://en.wikipedia.org/wiki/Year_2038_problem). These variables should be refactored to use 64 bit types, and some additional work is needed to ensure backwards compatibility where the timestamps are stored on disk.
Relevant coverity issues:
https://scan5.scan.coverity.com/reports.htm#v59282/p10114/fileInstanceId=237731889&defectInstanceId=53173981&mergedDefectId=1510535
(rgw_admin.cc)
https://scan5.scan.coverity.com/reports.htm#v59282/p10114/fileInstanceId=237731642&defectInstanceId=53158721&mergedDefectId=1523399
(rgw_torrent.cc)
Updated by Vedansh Bhartia 11 months ago
There are multiple places where we store timestamps in 32 bit types. These values will eventually overflow when time for a date on or after the year 2038 is stored (https://en.wikipedia.org/wiki/Year_2038_problem). These variables should be refactored to use 64 bit types, and some additional work is needed to ensure backwards compatibility where the timestamps are stored on disk.
Relevant coverity issues:
https://scan5.scan.coverity.com/reports.htm#v59282/p10114/fileInstanceId=237731084&defectInstanceId=53158561&mergedDefectId=1512048
(rgw_common.h)
https://scan5.scan.coverity.com/reports.htm#v59282/p10114/fileInstanceId=237731642&defectInstanceId=53158721&mergedDefectId=1523399
(rgw_torrent.cc)