Ashley Yakeley
It seems what should have been done was to create a patch to the kernel that allows the hardware clock to run on TAI but have gettimeofday return broken time as per POSIX, and have some other function to return TAI time. Perhaps someone's done this.
I tried to find out, with no success. Anybody? I'm about to reinstall my Linux laptop after a disk crash, so I could try to do this. It also appears that support is needed in NTP, although I'm not sure why.
Of course, even if the available clock uses broken POSIX UTC time, users might still want a leap-second table to convert to TAI.
I don't think UTC is broken, only POSIX and its time_t representation which quietly moves pushes the epoch a bit forward every leap second. UTC is the calendar specification, and not a counter, right? (I.e. UTC specifies the second "1998-12-30T23:59:60" as a perfectly good, normal second, while the corresponding POSIX time_t (and NTP second) is ambigous, and could mean the next (or previous?) second as well.) Am I the only one who feels that a calendar, unlike a clock, should specify particular time units (e.g. a particular day, hour, or second), and not infinitesimal points in time? So I would distinguish between the day "1998-12-30" and the hour "1998-12-30T00", for instance. I think this fits better with the applications I can imagine, but perhaps I'm a bit short on imagination? -kzm -- If I haven't seen further, it is by standing in the footprints of giants