[ntp:questions] Re: Y2038 bug strikes early

Richard B. Gilbert rgilbert88 at comcast.net
Wed Aug 2 02:16:49 UTC 2006


Garrett Wollman wrote:

> 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 
>>timestamps.
> 
> 
> 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.)
> 
<snip>

The available evidence (Y2K) suggests that the problem will not be 
addressed until 2036 at the earliest.  "It's not going to break in my 
working lifetime so why should I fix it?"!!!!!  As I recall the Y2K 
problem was first noted sometime in the 1970s.  It didn't need to be 
fixed for 25 years so nobody worried about it.




More information about the questions mailing list