Time Libraries Rough Draft

[Seth Kurtzberg]

Marcin 'Qrczak' Kowalczyk wrote:

>Daan Leijen <daan at cs.uu.nl> writes:
>
>  
>
>>- gettimeofday() returns the number of seconds since epoch (a UTC date)
>>
>>What kind of seconds does it return?  Well, (A) sometimes these are just
>>SI-seconds (which means we can derive TAI from that), but sometimes
>>(B) it returns UTC-seconds -- ie. the absolute SI-second count,
>>plus/minus
>>any leap seconds that have occurred.
>>
>>Is there anyone on this list who can give a solid overview of what
>>"gettimeofday" returns, and if we can distinguish (A) from (B)?
>>    
>>
>
>POSIX says it returns an UTC date, converted to the number of seconds
>by a given formula. The formula assumes that each day has 86400 seconds.
>
>With a strict reading of the definition, after a leap second one
>second is repeated (since 23:59:60 gives the same counter value as
>0:00:00 of the next day) and converting the time to hh:mm:ss never
>yields 60 as the number of seconds.
>
>NTP client is supposed to slow down the system clock at a leap second.
>If programs ask for the system time during a leap second, the clock
>progresses minimally, just enough to make time monotonic, and continues
>normally when it catches up with the UTC time. I don't know how well
>this is actually implemented.
>
>If a Linux time zone is set to something beginning with "right", then
>the system clock is assumed to count SI seconds since the UTC epoch
>(i.e. since 1970-01-01 00:00:10 TAI, even though TAI has been
>established in 1972) and leap seconds are adjusted together with the
>time zone. That is, gmtime() returns TAI, and localtime() returns
>localtime which is relative to UTC. If a standard NTP client is used,
>I guess it will set the time wrong, too early by 22 seconds (today).
>
>I think the only way to distinguish these cases is to call gmtime()
>and localtime() on the current time, and check whether the difference
>is a nice round number of minutes which is reasonable for a time zone
>difference, or it ends with a strange number of seconds which suggests
>that it includes leap seconds. This will work until the UTC-TAI offset
>reaches the smallest number which is a reasonable "fractional" part of
>a time zone offset.
>
>This scheme of detection breaks when a time zone offset itself is a
>strange number. For example glibc timezone tables include apparent
>noon times for Riyadh in 1987-1989 (a different time each day) -
>it seems they used that in Saudi Arabia then.
>  
>
The time was reset each day, I believe at sundown, but that's a somewhat 
hazy memory.  It was definitely reset each day based on some observed 
occurance (as in sun up, sun down, etc.)  I seem to remember that the 
time was reset each day at midnight, but I can't remember why that would 
have made any sense.  In any event, you are correct, there is nothing 
equivalent to a time zone for that situation.

I think it is fair to say they weren't terribly concerned about leap 
seconds either.  :)