301–310 of 456 posts
It is really convenient that the date changes whilst we all sleep. It makes 'today' and 'tomorrow' weird.
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…
Moral of the story is that sometimes social engineering is much cheaper and more effective than software engineering!
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…
Currently software has to be built to accommodate leap seconds. They happen frequently enough that you'll find out within a few years whether your software breaks when time suddenly skips forward or backward. If we kick the can down the road such that eventually we'll need to add a leap minute, we're going to end up with software that was never written to expect time to change in such a way, hasn't had a real world t…
Why would we ever need a leap minute? Just let time zones drift. Unless you happen to be at the exact longitude for which your time zone is correct, the sun's not at its highest point in the sky for you at exactly noon anyway. Eventually, thousands of years from now when time has drifted by an hour or more (assuming modern technological civilization even still exists by then), each jurisdiction can just change their…
Earlier quoted context omitted.
Why would we ever need a leap minute? Just let time zones drift. Unless you happen to be at the exact longitude for which your time zone is correct, the sun's not at its highest point in the sky for you at exactly noon anyway. Eventually, thousands of years from now when time has drifted by an hour or more (assuming modern technological civilization even still exists by then), each jurisdiction can just change their…
The last part is right and is also why we have this problem. Leap seconds are an architectural blunder that always belonged in the abstraction layer that lines up the sun with the rotation of earth (the time zone abstraction). It never belonged in the part that counts seconds.
Earlier quoted context omitted.
We just enabled leap second smearing on chrony.
I think that's the only reasonable way to handle this kind of thing, though I bet that accurate time matters enough in fintech that you'd still have some cases where you'd need access to the "true" wall time in order to stamp logs for auditing or whatever.
Earlier quoted context omitted.
Sometimes it pays to be the most-prepared among your cohort. In this case, it would have paid so well that your cohort decided to work around it. It always pays to not be the least-prepared among your cohort. You'll get no sympathy if you're at the back of the pack, you'll just die.
Another moral of the story could be that sometimes it's best to have a people solution to a technical problem.
Hot take: Leap seconds caused by astronomers refusing to modify their own software, instead getting the rest of the world to modify theirs. Too facile?
Any modern positioning system needs an accurate clock. Leap seconds aren’t completely predictable, so you can’t deploy something like a GPS unit with future leap seconds encoded. These computers are often spread across vast distances, so it’s the most difficult thing to possibly update.
E.g., suppose you made a system where each satellite transmits messages of the form "Here comes beep #N. At the time of beep #N this satellite is at this position: , , . Here is beep : BEEP!".
The satellites are synced so that beep occurs at the same time on all of them.
By looking at the time difference between the arrival of beep from several satellites a receiver could tell the differences between its distances from those satellites. Combined with the position information for those satellites at the time they beeped the receiver would be able to tell its location.
If the satellite broadcasts use a high enough frequency and that frequency is known and very stable the receiver would not even need an accurate stand alone timer. It could sync a counter to the frequency of the satellite radio.
Earlier quoted context omitted.
You don't have dst offsets for the future either. Those keep changing. That's not a blocker. The straight up truth is that we created something in between. Some parts of earth sun alignment are in the time zone abstraction layer and leap seconds are in the seconds count layer. There's no real cause for this and we should have moved to TAI to fix this blunder long ago.
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.
There's no reason this wasn't done many years ago except for a blunder on the part of CGPM which they are now working to correct.