[ntp:questions] Re: Y2038 bug strikes early

Garrett Wollman wollman at csail.mit.edu
Tue Aug 1 20:28:20 UTC 2006

In article <eaoan7$gj9$1 at scrotar.nss.udel.edu>,
David L. Mills <mills at udel.edu> wrote:

>Unix doesn't have to have a 2038 rollover problem, just as NTP doesn't 
>have a 2036 rollover problem. Evidence to this assertion has been 
>reported in recent messages to this list and the hackers at ntp.org support 
>group. It's all in the carefully designed 64-bit twos complement 
>calculations that determine the relative date and time

I'd like to see some evidence of these Unix(R) systems of which you
speak, with "carefully designed 64-bit twos complement calculations".

If you adhere to the Single UNIX Specification, your date and time
representation is determined by a formula in the POSIX standard.[1]
The result of evaluating that formula will exceed 2**31 in January,
2038 -- end of story.  One can hope that all systems in use by then
will have settled on a time_t type wider than that (or even better,
that time_t becomes an ill-remembered historical relic), and that all
applications which store times on disk or transmit them over the
network have done likewise, but I'm not counting on it.


[1] This formula is highly unlikely to change in the ongoing POSIX
revision, even though its representation of leap seconds is ambiguous.

Garrett A. Wollman    | As the Constitution endures, persons in every
wollman at csail.mit.edu | generation can invoke its principles in their own
Opinions not those    | search for greater freedom.
of MIT or CSAIL.      | - A. Kennedy, Lawrence v. Texas, 539 U.S. 558 (2003)

More information about the questions mailing list