Disadvantages of having a physics degree & being a bit of a timekeeping nerd:
-
@erincandescent PTP too, it's even more timekeeper-y than NTP.
Also I wish more people knew CLOCK_TAI existed. It's even fast on Linux (= in vDSO) these days.
-
BUT, what if the caesium doesn’t know this?
-
-
@equinox @erincandescent Looking at the documentation, I'm not sure I trust CLOCK_TAI: It sounds like it calculates TAI from POSIX time by undoing leapseconds, and it cannot be set, which seems backwards.
(My recollection of Linux's 2012 leapsecond bug is that it was caused by exactly that kind of backwardsness, so I guess nothing's changed.)
-
@erincandescent @snowfox indeed CLOCK_TAI works by setting CLOCK_REALTIME plus the (integer) kernel TAI offset…
…but I'm a strong believer in incremental steps and I'd really like to see more software use CLOCK_TAI (as appropriate), and tackle representation of leap-smearing separately (because these things don't block each other)
The thing more concerning to me is filesystem support for TAI timestamps
-
@equinox @snowfox IMO the lack of kernel support for non-integer or even algorithmic offsets is one of the biggest impediments to CLOCK_TAI use.
- Most systems don’t have a correct TAI<->UTC offset loaded anyway
- Making it correct requires making CLOCK_REALTIME non-monotonic (which breaks shit!)
- If you do it with leap smear it makes a mess
i.e. fixing shit really needs to start with the kernel, but clock_gettime is a super hot path…
-
@erincandescent @equinox Sadly I have to concede that leap-smearing is better than replaying a second like POSIX appears to specify, but the current popular implementation ("just make our NTP servers lie") is awful and makes accurate timekeeping even more difficult.
I've occasionally thought about running in TAI and using the "right" timezones and seeing what breaks.
-
-
@erincandescent @snowfox _something_ has started setting TAI offset correctly on at this point almost all of my systems — I suspect it's systemd but I'm not sure.
Either way, yeah, the kernel already has a "leap second upcoming, go step it" operation, it should really get an analog "leap second upcoming, start smearing it over X time" op, which can then leave TAI (and MONOTONIC!) on 1-physical-second ticks.
(And, yeah, MONOTONIC also being smeared in current smearing hacks is just an atrocity)
-
@equinox @erincandescent It wouldn't even need much kernel support: Just have a syscall that returns the current TAI timestamp, current leapsecond count, next leapsecond timestamp, and leap smear start/stop timestamps (or maybe number of seconds before/after to smear for). That's enough to calculate UTC and smeared-UTC for things that want it.
The leapsecond/smear information doesn't even need to be in the kernel, but being able to set/read it atomically along with the current timestamp might be handy.
-
