[ntp:hackers] Re: Unix time = %x40000000

Terje Mathisen terje.mathisen at hda.hydro.com
Tue Jan 6 23:06:21 PST 2004


David L. Mills wrote:

> Danny,
> 
> You can shame/blame me for NTP hijinks, but Unix is another matter. As
> in the millennium roll, the NTP timestamp has nothing to do with the
> Unix roll. On the other hand, if the Unix roll affects the NTP roll,
> that is not the NTP fault but a kernel malfeasance.

I agree completely.

In fact, I uploaded a patch to bug #46 yesterday evening which fixes 
these issues in the most portable way I know.

IMHO any unix system that wants to keep running after the end of the 
unix epoch (i.e. 2036) must fix the localtime() and gmtime() calls, right?

To do so, there's only two possible solutions:

a) Stay with a 32-bit time_t type, but implement some form of windowing, 
so that times after the rollover are converted to 2040 etc instead of 1906.

b) (Much better!) Extend the precision of time_t, usually all the way to 
a 64-bit type. This is the actual solution used by all those systems 
that have implemented a fix so far, afaik.

Anyway, this all means that the proper way to handle NTP epoch rollover 
is to simply convert the 32-bit NTP seconds count to a time_t type, add 
in the 70-year difference in base date, and then ask the OS to convert 
the result using the regular localtime/gmtime calls.

It is only when time_t has more than 32 bits that this can fail (on a 
working OS), and in that case we can add a multiple of 2^32 until the 
resulting date is in range.

Terje

-- 
- <Terje.Mathisen at hda.hydro.com>
"almost all programming can be viewed as an exercise in caching"



More information about the hackers mailing list