[ntp:hackers] prettydate and time_t

Danny Mayer mayer at gis.net
Sun Feb 18 15:20:05 PST 2007


Terje Mathisen wrote:
> hackers-bounces+terje.mathisen=hda.hydro.com at support.ntp.org wrote:
> 
> I wrote one of those secs to year/month/day functions for NTP a few
> years ago, I don't remember if this is the one.
> 
> Anyway, the "right way" to do this, imho, is to assume that the
> resulting year should be within +/- 68 of the current year, as returned
> from the OS.
> 
> My approach is to take the 32-bit ntp seconds value, then cast it to a
> time_t value and add the ntp-to-unix 70-year offset.
> 

Yes, but part of the problem is that the function ntp2unix_tm() expects
a u_long argument. In some O/S's long is a 64-bit quantity while in most
others it is a 32-bit quantity.

> Convert this value to y/m/d using gmtime() and compare with the current
> OS year: If the result is more than 68 years before the current date,
> add 2^32 secs and repeat until we're either relatively close, or a long
> time into the future. (If this happens, we're way off and should abend
> with a logged error.)
> 

I haven't seen an abend in years! :)

> The one real remaining problem is on those platforms where time_t is
> 32-bit: On those systems adding 2^32 will effectively do nothing, so the
> first conversion must be in range, or we must log an error.
> 
> Using this approach will allow the code to survive after 2036/2038 even
> on systems with 32-bit time_t, as long as the OS/lib routines that
> implement gmtime() have been patched to move the zero point 2^32 seconds
> forward, i.e. a one-time kludge to window the date conversion.
> 

Well we hope everyone is moving to 64-bit time_t.

Danny

> OK?
> 
> Terje


More information about the hackers mailing list