311–320 of 456 posts
Anybody who cares about leap seconds should have just been using TAI all along instead of UTC anyway.
In 2015 I was working at a "fintech" company and a leap second was announced. It was scheduled for a Wednesday, unlike all others before which had happened on the weekend, when markets were closed. When the previous leap second was applied, a bunch of our Linux servers had kernel panics for some reason, so needless to say everyone was really concerned about a leap second happening during trading hours. So I was assig…
The moral is we get to hear your cool war story. Thanks for sharing! ...okay yeah that's not a moral, but still.
$work had thousands of full custom, dsp-heavy, location measurement hardware devices widely deployed in the field for UTDOA locating cell phones. It used GPS for time reference -- if you know your location, you can get GPS time accurate around the 10's of nanoseconds. GPS also broadcasts a periodic almanac which includes leap second offsets: if you wanted to apply the offset to GPS you could derive UTC. Anyway there were three models of these units, each with an off-the-shelf GPS chip from one of three location vendors you've probably heard of. The chip firmware was responsible for handling leaps.
One day, a leap second arrived from the heavens. We learned the three vendors all exhibited different behaviors! Some chips handled the leap fine. Some ignored it. Some just crashed, chip offline, no bueno, adios. And some went into a state that gave wildly wrong answers. After a flurry of log pulling, debugging, console cabling, and truck rolls, we had a procedure to identify units in bad states and reset them without too many getting bricked.
It seems the less likely an event is to occur, the less likely your vendor put work into handling it.
I don't understand why this is necessary. We already have TAI (international atomic time) which is just UTC without leap seconds. It sounds like this committee voted to stop adding leap seconds to UTC, but not to "reset" the leap seconds that have already been added, effectively cementing a constant difference between UTC and TAI. What is the point? Anybody who cares about leap seconds should have just been using TAI…
I don't understand why this is necessary. We already have TAI (international atomic time) which is just UTC without leap seconds. It sounds like this committee voted to stop adding leap seconds to UTC, but not to "reset" the leap seconds that have already been added, effectively cementing a constant difference between UTC and TAI. What is the point? Anybody who cares about leap seconds should have just been using TAI…
The committee still wants UTC to be periodically adjusted to match the Earth's rotation. They just want to adjust it less often, where "less often" probably rounds to "never" in practical terms.
I don't understand why this is necessary. We already have TAI (international atomic time) which is just UTC without leap seconds. It sounds like this committee voted to stop adding leap seconds to UTC, but not to "reset" the leap seconds that have already been added, effectively cementing a constant difference between UTC and TAI. What is the point? Anybody who cares about leap seconds should have just been using TAI…
I've heard of the endless disruption that leap seconds cause for years and only now have I thought to ask the question: what was so important that the entire world needed to add or subtract individual seconds from the calendar? Seems like you'd need a pretty big justification for something like that, but I only here the horror stories, not what the leap second was supposed to actually solve.
In 1972 it was decided that the best way to compensate for this is to insert (and sometime remove) leap seconds, so that the difference between UTC and Earth’s rotation is kept below one second. A certain subset of astronomical and navigational/satellite applications rely on that condition being true. If this is changed, some decades-old systems, some of which may be critical infrastructure, may have to be substantially modified to account for leap seconds in some other way. The mention of GLONAS in the article is one such example.
In the international standard body responsible for UTC (ITU-R), there was up to now no sufficient majority in favor of abolishing leap seconds, due to those concerns. (Never change a running system, so to speak.) By now it has become apparent that the benefits of dropping leap seconds should vastly outweigh the potential drawbacks, at least for the next few decades. But it took some time for that realization, and probably also some older participants whose minds couldn’t be changed to die off.
I don't understand why this is necessary. We already have TAI (international atomic time) which is just UTC without leap seconds. It sounds like this committee voted to stop adding leap seconds to UTC, but not to "reset" the leap seconds that have already been added, effectively cementing a constant difference between UTC and TAI. What is the point? Anybody who cares about leap seconds should have just been using TAI…
The committee still wants UTC to be periodically adjusted to match the Earth's rotation. They just want to adjust it less often, where "less often" probably rounds to "never" in practical terms.
Earlier quoted context omitted.
You don't have DST offsets at all in UTC, which is probably how you are storing timestamps, so you can always compute a delta between timestamps if you don't have leap seconds.
That's the whole point i'm making here. UTC and leap seconds could always have been separate in the same way timezone+dst offsets are separate. In fact leap seconds could have just gone into the timezone offsets directly and it'd all work fine (we'd probably still call it UTC +10 rather than UTC +10:00:27 but that's not a problem and to be honest we'd probably not bother at all until the offset was big anyway). There…
In 2015 I was working at a "fintech" company and a leap second was announced. It was scheduled for a Wednesday, unlike all others before which had happened on the weekend, when markets were closed. When the previous leap second was applied, a bunch of our Linux servers had kernel panics for some reason, so needless to say everyone was really concerned about a leap second happening during trading hours. So I was assig…
Earlier quoted context omitted.
That's the whole point i'm making here. UTC and leap seconds could always have been separate in the same way timezone+dst offsets are separate. In fact leap seconds could have just gone into the timezone offsets directly and it'd all work fine (we'd probably still call it UTC +10 rather than UTC +10:00:27 but that's not a problem and to be honest we'd probably not bother at all until the offset was big anyway). There…
Well, in principle there’s TAI for that. But civil time in most countries is defined in terms of UTC/GMT.
But we're here now and we have to fix this. So anything that moves us away front his problem is helpful.