Not logged in
Log in now
Create an account
Subscribe to LWN
LWN.net Weekly Edition for May 23, 2013
An "enum" for Python 3
An unexpected perf feature
LWN.net Weekly Edition for May 16, 2013
A look at the PyPy 2.0 release
Do people not understand how leap seconds are implemented? Really?
Not, as Red Hat seems to think:
Or, as google seems to think would be a Good Idea:
with *seconds being 1/86,401th of a second longer than other days* (no, I am not making any part of that up).
Re: [PATCH 0/2][RFC] Potential fix for leapsecond caused futex issue (v2)
Posted Jul 2, 2012 16:24 UTC (Mon) by Baylink (subscriber, #755)
ISO8601 actually permits 60 as a valid seconds count, for precisely this reason.
I had thought that it, for some reason, permitted 61, too, but I was worng.
Posted Jul 4, 2012 7:12 UTC (Wed) by butlerm (subscriber, #13312)
Changing the kernel's internal time base to use something TAI derived instead of UTC derived is probably the only way to fix this problem reliably. The downside is that means the kernel would have to maintain a leap second table and convert back and forth between POSIX time and linear time where necessary.
Posted Jul 2, 2012 16:27 UTC (Mon) by lindi (subscriber, #53135)
Isn't this exactly the correct behavior?
Posted Jul 2, 2012 17:24 UTC (Mon) by Jonno (subscriber, #49613)
However, there was some internal kernel code that expected to be informed when the time of day and elapsed time wasn't continuous (done by calling clock_was_set()). The code for settimeofday() got this right, but the clock_was_set() call was missing from the leap second introducing code, leading to some trouble I don't really understand.
Posted Jul 2, 2012 18:53 UTC (Mon) by jhhaller (subscriber, #56103)
To use glibc with leap seconds, "right" timezone files must be used, e.g. US_Central_right. This allows the ISO version of timestamps to be used, and the clock will indeed tick at 235958, 235959, 235960, 000000. These are not the default timezones, for reasons described below. Note that this requires that the number of seconds since January 1, 1970 must account for all leap seconds.
To use glibc with the conventional timezones, there is no notion of leap seconds. This is the way ctime has worked since the beginning. It assures that every year will have the same number of seconds, except for leap day years, which have an extra day. This obviously causes problems when there is a leap second, as a second has to be played twice from the kernel, as the kernel clock can't know about leap seconds since ctime doesn't. There is no way in the current interfaces to report a time plus report that this kernel time represents a leap second. Also, the Posix definition for time does not account for leap seconds. The only way to do this is to replay the time value for second 59, as ctime has no way to know a leap second is coming to show the displayed second as 60.
Now, to throw NTP into the mix. The NTP protocol reports time in UTC, which is ephemeral or solar time. There is no history of leap seconds in the UTC protocol, just an indication that an upcoming minute at the end of the day will have 59, 60, or 61 seconds. While NTP could in theory run with the "right" timezones, and add or subtract historical leap seconds when setting the system time, that would make the time returned from the time call to be incorrect according to Posix.
In short, Posix is inconsistent with itself, or at least needs a new kernel API to reflect historical leap seconds, both for time and adjtime, although it appears that this was known when the time system call was standardized.
Posted Jul 2, 2012 20:18 UTC (Mon) by chip (subscriber, #8258)
Posted Jul 2, 2012 20:36 UTC (Mon) by Thue (subscriber, #14277)
Time zone and leap second offsets should be added in user space programs, the same way I assume time zones currently are.
Posted Jul 2, 2012 20:45 UTC (Mon) by chip (subscriber, #8258)
Posted Jul 2, 2012 21:08 UTC (Mon) by Thue (subscriber, #14277)
Posted Jul 2, 2012 21:40 UTC (Mon) by chip (subscriber, #8258)
Posted Jul 2, 2012 22:05 UTC (Mon) by Thue (subscriber, #14277)
gradual clock adjust
Posted Jul 2, 2012 23:11 UTC (Mon) by pflugstad (subscriber, #224)
Note that they don't explicitly say over what time window they adjust the time, but my impression from the above article is that it's done over a few hours, not over an entire day.
Posted Jul 3, 2012 14:19 UTC (Tue) by Tobu (subscriber, #24111)
Copyright © 2013, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds