[ntp:questions] Re: NTP, Unix and the 34-year itch (better read this)

Terje Mathisen terje.mathisen at hda.hydro.com
Thu Jan 22 14:14:17 UTC 2004

Hal Murray wrote:

>>Almost all computers of today have some means, such as a time-of-year
>>(TOY) chip, to set the system clock at power up or reboot surely within
>>within 34 years, but some embedded systems do not. For embedded systems
>>without a TOY chip and running an embedded Unix kernel, the initial time
>>is usually the Unix base epoch 1 January 1970. Readers will quickly
>>realize the time since then now in 2004 exceeds the 34-year limit. These
>>systems have a problem unless something is done.
> Another case to consider is the battery running down.  That happens
> after a while if the box is not plugged in.
> Another way to get a good starting epoch would be to use the 
> build time of the kernel.

Even better, and easier to get for an ntpd deamon:

The build time of the ntpd deamon itself: This will then be good for the 
next 34 years, and any system which can run without recompilation for 34 
years deserves a _lot_ of respect.

In fact, I suspect such a system will be well-engineered enough to have 
a working TOY clock.

Even if the TOY clock breaks (battery stops working after ~5-10 years), 
simply demanding that the initial time is >= the build time would suffice.

Alternatively, use the file system level timestamp of the ntpd deamon:

If you're really paranoid/scared, you could run 'touch ntpd' (or a 
companion date flag file) as part of the normal shutdown sequence, this 
would work for all systems with less than 34 years between reboots.

However, since the 34-year limit is for ntp time differences, a 68 or 
even 136 year range should work for ntp absolute times, i.e. ntpdate or 
ntpd -g initial time setting.


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

More information about the questions mailing list