Description of problem: gmtime and localtime produce incorrect output for time values after January 19, 2038 03:14:07 GMT. Version-Release number of selected component (if applicable): glibc-2.3.2-101 How reproducible: Run the attached test program. Steps to Reproduce: 1. 2. 3. Actual results: time = 2038-01-19 03:14:07 time = 2038-01-18 19:14:07 time = 1901-12-13 20:45:52 time = 1901-12-13 12:45:52 Expected results: time = 2038-01-19 03:14:07 time = 2038-01-18 19:14:07 time = 2038-01-19 03:14:08 time = 2038-01-18 19:14:08 Additional info:
Created attachment 98387 [details] Test case
This is a WONTFIX for 32-bit arches, sorry, but I don't think there will be many 32-bit arches out there in 34 years from now. [jakub@hammer obj]$ ./test time = 2038-01-19 03:14:07 time = 2038-01-19 04:14:07 time = 2038-01-19 03:14:08 time = 2038-01-19 04:14:08 works just fine. With the advent of AMD64 and IA32e I think most of the computers out there will be 64-bit already within at most 5 years. If 32-bit platforms are still around in big enough quantities in 2030, this can be certainly reconsidered, but until then it is just a waste of time.
There are things, such as CA certificates, mortgage amoritizations, etc. that need to deal with dates 35 or more years into the future. I wouldn't have filed the bug if I hadn't encountered it. It prevents openssl from being able to create a cert with a liftime past 2038.
Then openssl needs to use its own timekeeping, it is as simple as that. gmtime/localtime is not an API to work with any time in the history/future. It will not handle pre-1900 dates either and similarly to this, applications which need to work with such dates need to handle it on their own.