Bug 117821

Summary: y2038 bugs in gmtime, localtime
Product: [Fedora] Fedora Reporter: John G. Myers <jgmyers>
Component: glibcAssignee: Jakub Jelinek <jakub>
Status: CLOSED WONTFIX QA Contact: Brian Brock <bbrock>
Severity: medium Docs Contact:
Priority: medium    
Version: rawhideCC: dbaron, mitr
Target Milestone: ---   
Target Release: ---   
Hardware: i586   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2004-03-22 17:38:57 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Attachments:
Description Flags
Test case none

Description John G. Myers 2004-03-08 22:58:15 UTC 
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:
Comment 1 John G. Myers 2004-03-08 22:58:55 UTC 
Created attachment 98387 [details]
Test case
Comment 2 Jakub Jelinek 2004-03-09 13:59:59 UTC 
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.
Comment 3 John G. Myers 2004-03-09 18:46:45 UTC 
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.
Comment 4 Jakub Jelinek 2004-03-22 17:38:57 UTC 
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.