David J Taylor wrote: > Richard B. gilbert wrote: > [] > >>It's hardly ever a problem since most systems have a hardware clock of >>some sort that can supply a reasonable starting point. In 2007, I >>don't think that 1970-is a reasonable starting point. > > > Whilst I have some sympathy for that viewpoint, NTP should not today have > that 30-year limitation (delighted to hear it is being extended). > > It is not a defect of the OS that it allows its real-time clock to be set > /before/ the base time - 1970? > > David > >
The "30-year" limitation is really, I believe, 36 years. It's a artifact of the data structures used by the current implementation; a sixty-four bit word with the binary point in the middle is used to represent the seconds and fractional seconds since 1-JAN-1970. This has served us well for the last 20 years or so. I believe that the new standard is going to call for a 128 bit word which should last a few years longer. :-) The fault, if any, is the way Unix keeps time. I believe it's a signed 32 bit integer keeping seconds since 1-JAN-1970. Digital's VMS used a scheme that could represent any time from a base time in November 1857 through the next 30,000 years or so. Unix time, at least until recently, would overflow in 2036. _______________________________________________ questions mailing list [email protected] https://lists.ntp.isc.org/mailman/listinfo/questions
