[ntp:questions] Re: Y2038 bug strikes early

Garrett Wollman wollman at csail.mit.edu
Tue Aug 1 23:02:27 UTC 2006

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

>The issue has nothing to do with Unix or POSIX. It has to do with NTP 

That's great for NTP but isn't responsive to your original claim:

>>>Unix doesn't have to have a 2038 rollover problem, just as NTP doesn't 
>>>have a 2036 rollover problem.

UNIX brand operating systems are not (under current standards)
permitted to do the sort of epoch-windowing you describe and NTP
implements.  Thus, the only solution to the Y2038 problem which
comports with the requirements of the standard is to make time_t be a
wider type.[1]  As you note, many operating systems are now using a
64-bit type internally, but applications and protocols have failed to
keep up.  The concern for the industry is, will we find and fix all
those systems in time?  (I hope, given how much the pace of change has
increased, that this will be a non-issue in thirty years' time.)


[1] Every time in recent memory that the POSIX committee has tried to
tackle the leap-second bug, someone always pops up and insists that
the Y2038 problem must also be solved at the same time (by increasing
the required range of time_t).  This then gets tangled up with the
issue of finer-resolution file timestamps and the whole mess goes into
a rathole, not to be seen until the next round of revisions.

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