Hi!
I was currently following some discussion on the topic of leap seconds, and due
to the basic role of time in the kernel, I'd like to send a "heads up" ("food
for thought") with some proposal (not to start some useless discussion):
The UNIX timescale running in UTC had (I suppose) the idea that no timezone
switches will affect it. Unfortunately leap-seconds have not been considered;
maybe also because at that time everybody would be happy if the system's time
was correct to a few seconds. I don't know.
However leap seconds are a kind of "time zone switch" conceptually.
Unfortunately the unix time scale does not consider them (as noted in the
time(2) manual page). That's one part of posix. The other part of POSIX claims
that during an inserted leap second there should be a 61st second in the
minute. Unfortunately (AFAIK) there's no interface from kernel's leap second
handling to glibc allowing it to actually return 60 as the number of seconds.
(localtime(3) only gets a pointer to time_t)
OTOH in the NTPv4 clock model there is a TAI offset included (which can be
updated by NTP). AFAIK the kernel also has the timezone offset for some time to
handle RTCs that run local time. Obviously if the kernel knew the number of
leap seconds (the correction to the time() timescale) conversion from UNIX
timescale to TAI would be easy.
So roughly if the kernel exports the time and type of the next_leap second
scheduled, some future localtime could actually return the 61st second in the
minute. As it is now applications will all see some magic duplication of the
60th second. (Maybe that' why Google does "leap smear"). If the kernel API
would also export the TAI offset, one could even offer a TAI-based time, or,
maybe even better: The kernel could run on TAI internally, and convert to UNIX
time scale as needed.
I'll leave exact specification and implementation to the really clever guys.
Regards,
Ulrich
P.S. Not subscribed to the kernel-list so if you want to talk to me keep me on
CC: preferably
