[ntp:questions] Re: Y2038 bug strikes early
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.
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.
 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