[ntp:hackers] prettydate and time_t

David L. Mills mills at udel.edu
Sun Feb 18 14:28:55 PST 2007


Guys,

Some of the library routines date from 11984 when a C long was 32 bits.. 
and a C int was 16 bits. The macros should probably be rewritten. On 
Alpha a time_t is 64 bits. I think all references in ntp for the seconds 
value should be time_t, not u_long, since unix and ntp have the same 
semantics.

Terje Mathisen wrote:

> hackers-bounces+terje.mathisen=hda.hydro.com at support.ntp.org wrote:
> > Dave,
> >
> > I've been looking at functions like prettydate() in 
> /libntp/prettydate.c
> > while fixing some issue with using a 64-bit version of time_t on 
> Windows
> > and I noticed that the code uses time_t and u_long almost
> > interchangably. The main culprit is that ntp2unix_tm() uses u_long for
> > it's argument. The main question for you is whether or not it should be
> > using a u_long for ntp times (as expressed in the l_fp structure) where
> > the secs are expressed through a 32 bit structure. Note that time_t and
> > u_long can be of different lengths on different platforms. If the 
> intent
> > is not to use anything longer than 32 bits, I can define sec as u_long
> > which is how it's used in ntp2unix_tm(), though u_long is defined as 64
> > bits on some platforms.
>
> 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.
>
> 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.)
>
> 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.
>
> OK?
>
> Terje
>
> ------------------------------------------------------------------------
>
>
>
> ***********************************************************************
> NOTICE: This e-mail transmission, and any documents, files or previous
> e-mail messages attached to it, may contain confidential or privileged
> information. If you are not the intended recipient, or a person
> responsible for delivering it to the intended recipient, you are
> hereby notified that any disclosure, copying, distribution or use of
> any of the information contained in or attached to this message is
> STRICTLY PROHIBITED. If you have received this transmission in error,
> please immediately notify the sender and delete the e-mail and attached
> documents. Thank you.
> ***********************************************************************
>



More information about the hackers mailing list