[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