Daan Leijen
- 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@knm.org.pl ^^ http://qrnik.knm.org.pl/~qrczak/