Comment by globular-toast
3 days ago
I knew we wouldn't do a negative leap second. Leap seconds have been in from the start so all software should be able to handle them. But obviously we have no confidence in that actually being true. I suppose it shows that already, pre-AI, we don't really understand everything that we've built.
> Leap seconds have been in from the start so all software should be able to handle them. But obviously we have no confidence in that actually being true.
We in fact have high confidence that it’s not true. Google started leap smearing back in 2008 because so much broke on leap seconds.
Honestly I’d think a negative leap second would have way higher chances of just working than positive: a positive leap second causes a UTC minute to have a 61st second, and a unix timestamp to repeat. That is a highly rare condition and plays complete havoc on software which does not specifically support these.
A negative leap just means jumping a second, this is already relatively routine due to scheduling and suspends, your program can do one thing and then 20 minutes occur before the next, because right then the user closed their laptop lid.
Yeah, I don't get why negative ones are more scary than positive. I think it's just fear of the unknown because we haven't had one before.
This, I think.
Coming from someone whose daily work has been time sync for years (me):
If you look at Linux and many other Unix and Unix-like systems, to me it's the insertion of a leap second that has more potential for a failure than a removal.
Insertion ("positive leap seconds"): Time formatting functions will output "hh:mm:60" - this in itself is bound to catch some sofware off-guard - but internally during an insertion the same epoch value runs twice: 123456789.999999999 -> 123456789.000000000, which again is bound to cause some amount of confusion to assorted systems, and clearly the smear was implemented to combat this.
Surely this must be worse than the removal ("negative leap seconds"): 123456789.999999999 -> 123456790.000000000 - yes, still a discontinuity, but we have continuous increase and no ":60".
During my time spent developing time sync architectures and software, I tested both, ad nauseam, and tested it for others, a lot, GNSS simulators and all. Clearly precision time sync remains a specialised discipline, and pays my bills, so I don't mind, but I think this is a case of FUD combined with poor engineering practice and inadequate software testing eventually defeating a well-established timekeeping practice that (now this is more poetical than factual) allowed us to keep our timekeeping aligned with "nature".
I actually think we're in for a bigger mess when after this resolution we attempt to big-bang a batch update, but I will be retired and actually more likely dead and gone by the time this happens, so...
1 reply →