From: Helge Hafting <helgehaf@idb.hist.no>
Subject: time_t size: The year 2038 bug Summary:
Date: Mon, 10 Jan 2000 13:17:32 +0100
> >hence Linux will have the
> >2038 bug.
> >
> >That said, how do we fix it? Or is it something we just believe will
> >fix itself? It sounds like it is both a kernel and a libc issue. It also
> >seems to me that the easiest thing is to go to 64 bits.
>
> Seems to me the ideal fix is to add 64-bit time, but keep the 32-bit
> interface for compatibility reasons. When 2038 comes the compatibility
> interface breaks, while most people hopefully use the 64-bit interface
> by then.
>
> People may start fixing libs and apps as soon as the kernel interface is
> there,
> it is hard to start earlier. This is a good reason to do it early.
> Using 64-bit values on a 32-bit machine is of course a bit slower, but
> that's merely a reason for upgrading.
Actually, there is a good thing in these 32 bit numbers as was pointed out.
If you add a 64 bit interface next to the existing time_t interface you can
only relly on the 64 bit interface for "true" time where as the 32 bit will
be usefull as a smaller timestamp. So, if you only want correct time you
should use this timel_t and if you go about and use time_t then you need to
rely on timel_t for actual year. This will be true up to about Y585G (now
that SI units got so popular). This time is way past when universe is
supposed to have ended and reappeared a few times... given that the timel_t
still ticks in seconds. If this seems excessive we could let timel_t tick
in microseconds which would be an interesting balance between enougth bits
to avoid year wrap around and being able to mark time. Such a timel_t would
not harmonize with the NTP and RTP wallclock thougth.
NTP 3 (RFC 1305) allready have a 64 bit format for wallclock where the top
32 bits are the number of seconds since 00:00:00 on the 1 January 1900.
The NTP 3 time will roll over in year 2036 (the value is 64 bit unsigned).
Interestingly enougth this will give you a timing precission of about 200 ps.
The interested reader can get both some good info and a few laugths by reading
RFC 2550 - "Y10K and Beyond" which actually number up a few of the problems.
So, if we have to stick with the old time_t and can not accept going from
signed to unsigned we have to do some other solution. A strait extension is
one way, a 8 bit shifted NTP solution is another way. Maybe just directly
head for a 128 bit NTP type thing (64 bit seconds and 64 bit fractional
seconds) would be usefull ;)
Cheers,
Magnus
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Sat Jan 15 2000 - 21:00:18 EST