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

Terje Mathisen terje.mathisen at hda.hydro.com
Fri Jan 23 08:23:01 UTC 2004

Simon Burge wrote:
> Harlan Stenn wrote:
>>One could certainly use the timestamp on that file as *a* way to try and
>>find the ballpark, but as I recall the embedded systems folks often have
>>problems writing files like that and want to avoid them.
> Note that we already have some date info in the ntpd binary - the
> version string from version.c.  From a recent build:
> 	"ntpd 4.2.0a at 1.1210-r Wed Jan 14 01:33:04 EST 2004 (1)"
> Maybe this can somehow be used in a sanity check?

It could indeed be used, and if the date stamp of the ntp.drift file is 
not more than a reasonable number of years ahead of it, the drift file 
timestamp could extend the range even further.

However, simply setting a basic requirement that the initial time _has_ 
to be greater than the build time, would be sufficient to get into the 
proper 136-year epoch.

Even if that should optimally be 1/2 (68 years) or 1/4 (34 years) the 
full range, I really cannot see a way to run an unmodified binary for 
more than 34 years, much less 68 or 136!

Even if you absolutely cannot modify the ntpd binary code, hex-editing 
the string to update the year should be fefasible even for embedded devices.


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

More information about the questions mailing list