leap seconds and 61st second in minute

[Ulrich Windl]

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