[ntp:hackers] prettydate and time_t

David L. Mills mills at udel.edu
Sun Feb 18 21:25:55 PST 2007


Danny,

Well, actually it wasn't me; it was Dennis Fergusson, then of U Toronto. 
Dennis did the magic assuming the biggest elephant around was 32 bits. I 
did the extensions for floating double.

Dave

Danny Mayer wrote:

> David L. Mills wrote:
>
>> 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.
>>
>
> Dave,
>
> That means taking another look at the l_fp structure in ntp_fp.h. I'm
> afraid to touch something as fundamental as that without your review and
> input.
>
> Danny
>
>> 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
>>



More information about the hackers mailing list