Note: This bug is displayed in read-only format because the product is no longer active in Red Hat Bugzilla.

Bug 8210

Summary: Jan 18, 2038 problem
Product: [Retired] Red Hat Linux Reporter: Doug Springer <doug>
Component: gccAssignee: Nalin Dahyabhai <nalin>
Status: CLOSED NOTABUG QA Contact:
Severity: low Docs Contact:
Priority: medium    
Version: 6.1CC: doug
Target Milestone: ---   
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2000-01-05 19:04:06 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:

Description Doug Springer 2000-01-05 18:57:30 UTC 
I realize I will probally be flamed, but who is working to fix the current
time format for the compiler?  January 18,2038 as I figure it will appear
to be Jan 1, 1970.  Any planned fixes?  Who will do it?  Who can I talk to
about this issue?  It would be nice to know Linux already has the solution
to this wide-spread issue.

Ok, now flame me....
Comment 1 Jim Kingdon 2000-01-05 19:04:59 UTC 
This is more of a kernel and glibc issue than a compiler issue.  If you
do some searches on the net you should be able to find something about
64 bit time_t's (maybe on one of the Debian lists?  I don't remember
where I saw it).

You can start working on this (e.g. try changing time_t and see what breaks);
if you want to get in touch with other people who might want to work on
the same issue I suppose the glibc and kernel email lists are the most obvious
place.