Time Libraries Rough Draft

[Marcin 'Qrczak' Kowalczyk]

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.

-- 
   __("<         Marcin Kowalczyk
   \__/       qrczak at knm.org.pl
    ^^     http://qrnik.knm.org.pl/~qrczak/