[ntp:questions] Re: Y2038 bug strikes early

David L. Mills mills at udel.edu
Tue Aug 1 22:22:21 UTC 2006


The issue has nothing to do with Unix or POSIX. It has to do with NTP 
timestamps. There are two sources of evidence, the page I referenced, 
and actual test with Solaris 10 and current NTP daemon ntpd. Set the 
Unix clock in the server to early 2037; set the client to the current 
date and start with the -g option. Try this the other way around as 
well. All this proves only that the NTP rollover will be transparent as 
long as Unix is transparent beyond 2038.

It is important to note that NTP calculations never assume an absolute 
value, only an offset relative to 136-year eras. Native Unix timekeeping 
could do the same thing with result calculations spanning Unix eras 
would be unambiguous as long as the difference between two timestamps 
did not exceed 34 years (because Unix seconds are signed).

Modern kernels I have seen represent seconds in 64-bit twos complement 
signed integer, which is the same as in the NTP date format. While the 
base era for NTP is 1900 and for Unix is 1970, the 64-bit signed seconds 
field can represent seconds since before the big bang until after the 
Sun grows cold.


Garrett Wollman wrote:
> 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.
> -GAWollman
> [1] This formula is highly unlikely to change in the ongoing POSIX
> revision, even though its representation of leap seconds is ambiguous.

More information about the questions mailing list