Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The leap second’s time is up: world votes to stop pausing clocks

nature.com

Post reply on HN
Print view View original

211–220 of 456 posts

Re: The leap second’s time is up: world votes to stop pausing clocks

#211

Post by martyvis »

modernpink wrote: post #173
hoytech wrote: post #103

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…

>I spent a month in the lab Do you mean at your desk? What is a lab in a fintech context?

For most of us that are doing implementation engineering, a lab is simply a collection of the gear that can be put together in a simulation of the production environment without being constrained by formalities. For me it would be a bunch of network and server kit and cables in a rack.

Re: The leap second’s time is up: world votes to stop pausing clocks

#212

Post by ronsor »

layer8 wrote: post #181
finnh wrote: post #97

> The CGPM — which also oversees the international system of units (SI) — has proposed that no leap second should be added for at least a century, allowing UT1 and UTC to slide out of sync by about 1 minute. So, in one century, we'll get 1 minute's worth of drift. Recall that we all share the same clock within timezones, and 1 minute of drift between atomic & solar clocks is the equivalent of traveling 1/60th of your…

The problem is mostly (or so I’ve heard) that the drift is relevant for astronomical applications, and they rely on time dissemination which is done in UTC. If UTC decides to start deviating from TAI by dropping leap seconds, those applications will be in trouble. I’m sure that the problem is overblown, but this is the reasoning that was put forward in the past.

People who are using time for astronomical applications will simply have to track the offset if they need to. I'm not sure how that's much more problematic than the current situation.

Re: The leap second’s time is up: world votes to stop pausing clocks

#213

Post by pmontra »

hoytech wrote: post #103

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…

Contingency plans have their own contingency plans. Maybe trading companies started talks to stop the market months before your company assigned that task to you, in case of no agreement or a negative one.

Re: The leap second’s time is up: world votes to stop pausing clocks

#214

Post by smcameron »

adamsb6 wrote: post #50

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…

Nah, you just smear time faster or slower so you never need to "leap".

Re: The leap second’s time is up: world votes to stop pausing clocks

#215

Post by bombcar »

layer8 wrote: post #154
bombcar wrote: post #84

Earlier quoted context omitted.

I've always thought that the best way would just have leap seconds every six months, and have it be ± 1 second no matter what - so sometimes you'd go back a second twice in a row, and then go forward a second to get back to correct. That'd test all the software paths.

Better make it every other day rather than every six months.

Henceforth every minute will be "bell curve distribution around 60" seconds long, and each hour will be "bell curve distribution around 60" minutes long.

This variability will provide excellent fuzzing of all time libraries everywhere.

Re: The leap second’s time is up: world votes to stop pausing clocks

#216

Post by msla »

hoytech wrote: post #103

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…

Don't conclude it's that hard for everyone until you've spoken to a good subset of different people.

You're conscientious and willing to dig in to the details to fix a problem. Plenty of people aren't, and plenty of those are doing the same job as you. Look up from your own little world and try to figure out what other people are doing, how they're doing it, and why. This applies generally: If you fixate on a specific language or toolkit, you'll miss others which fix or obviate bugs you were resigned to living with. Same with OSes and environments. It even applies to relationships, which is why a big hallmark of abuse is isolating the victim.

Re: The leap second’s time is up: world votes to stop pausing clocks

#217

Post by xmprt »

ycombobreaker wrote: post #141
hoytech wrote: post #103

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…

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.

Re: The leap second’s time is up: world votes to stop pausing clocks

#218

Post by clysm »

jylam wrote: post #59

It seems I've got an unpopular opinion reading the comments here, but having some leap seconds from time to time ensure we are able to manage them. But "no leap second should be added for at least a century" ensures there will be a y2k reckoning every century. Seems short sighted to me, even if it is not a game-changing issue, let's be honest.

The difference should be handled at the same layer as time zones, which is already a mess and is already well-suited to deal with this type of thing.

I'd argue there should be no adjustment until it gets to be +- 15 minutes from UT1. And even then, NO clock skewing, just a time zone adjustment across the board.

Re: The leap second’s time is up: world votes to stop pausing clocks

#219

Post by jimmaswell »

arcticbull wrote: post #205
jimmaswell wrote: post #190

Earlier quoted context omitted.

Think of all the time that could be better appropriated than on fintech in general. Seems like such a waste of resources siccing a bunch of computers against each other in a zero sum game of stock arbitrage. I will admit some of the stuff tech comes out of it is cool on its own at least.

Fintech covers the entire payments space too

Guess I'm thinking more of HFT. Normal payment processing isn't this affected by a leap second though as far as I know.

Re: The leap second’s time is up: world votes to stop pausing clocks

#220

Post by myself248 »

lifthrasiir wrote: post #162
techdragon wrote: post #80

Hot take… Storing anything as UTC was a mistake and we should be using TAI for all storage and computation, only transforming into more human friendly formats for display to end users. This never needed to be a problem except we decided to make it harder to use TAI than UTC and so everything got built up off the backs of legacy bios level hardware supported UTC style clock behaviour, when we should have been using TA…

I now realized that the parent meant everything should have been TAI from the beginning, which is indeed a valid take. We can't switch to TAI today only because we are already using UTC. Original comment: Only those who never tried to actually use TAI yourself can claim that you can use TAI instead of UTC without a problem.

Just have 37 leap seconds to bring UTC into sync with TAI, then lock them together.

That won't break anything...

Post reply on HN