Leaping seconds and looping servers

Leaping seconds and looping servers

> It would not just break POSIX but a huge number of applications

Very few application does syscalls directly, almost everyone goes through glibc which already converts times using tzdata to get time-zone handling correctly.

> unless you complicated glibc to do the conversion, in which case it would still be obviously broken in some major cases, as the time you got from gettimeofday() would be different from the time visible on a file you just created when you stat()ted it

Of course not, all not-time-zone-aware times would be TAI, and all time-zone-aware times would be correct for that time-zone. UTC would be just another time-zone (which it already is, though today the kernel-time to UTC conversion is trivial).

> And for what benefit? Moving a pile of complexity [...] into glibc and a vast body of applications.

Applications would need no more complexity than what they already need for correct time-zone handling. The small number of applications that lacks that (small) complexity today and thus uses UTC exclusively (and are thus wrong for all users at least half the year) would just start using TAI instead (and thus be wrong for all users all year). All other applications would work just fine without any change.

tz-data would need to start carry leap second information, and glibc would need to make use of it, but that is trivial compared to what they already deal with (leap seconds are after all the same in all jurisdictions).

The only real problem is handling the transition correctly. I believe there would only have to add fixes to three components for it to work.

• glibc would need to detect the kernel version and decide whether to use the leap second information from tz-data depending on whether the kernel runs in UTC or in TAI.
• hwclock would need to use glibc to convert between UTC and kernel time (just like it does today when it converts between local time and kernel time for dual boot system whose BIOS clock runs in local time).
• NTP would need to either introduce a flag day when the NTP pool switches from UTC to TAI, or (more likely) adding some compatibility code so new NTP versions that speak TAI can communicate with old NTP versions that speak UTC.