Bug 8210 - Jan 18, 2038 problem
Jan 18, 2038 problem
Status: CLOSED NOTABUG
Product: Red Hat Linux
Classification: Retired
Component: gcc (Show other bugs)
6.1
All Linux
medium Severity low
: ---
: ---
Assigned To: Nalin Dahyabhai
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2000-01-05 13:57 EST by Doug Springer
Modified: 2008-05-01 11:37 EDT (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2000-01-05 14:04:06 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Doug Springer 2000-01-05 13:57:30 EST
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 14:04:59 EST
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.

Note You need to log in before you can comment on or make changes to this bug.