Live data from Hacker News

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

nature.com

171–180 of 456 posts

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

#171

> How, and whether, to keep atomic time in sync with Earth's rotation is still up for debate. […] > 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. But it plans to consult with other international organizations and decide by 2026 on what upper limit, if any, to…

The drift is sufficiently slow that you can fix it with a "leap hour" when needed -- perhaps once every five thousand years. This could be handled for civil/local time via an adjustment in the timezone definitions (something which happens a few times a year today), leaving the underlying UTC timebase unchanged.

The main difficulty is convincing Greenwich to not be utc+0 anymore.

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

#172

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…

You got paid to dig extremely deeply into a very complex and important problem spanning multiple systems and domains. You developed a plan, tested it and were ready to act.

This is a hugely valuable learning experience few people even get a chance at, let alone solve. Too bad it doesn’t show up on your resume is the only downside!

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

#173

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?

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

#174

I trust we will also be getting rid of leap years: that whole pausing the calendar for a day thing is very confusing. Oh wait, that's not how it works. And neither is it how leap seconds work.

Those are very different scenarios, they aren't equivalent.

Leap years have to do directly with the sun, what day and time the equinoxes happen every year and the like. This time noticeably drifts every year, even every day, computers or not.

These leap seconds and what not have to do with very sensitive instruments measuring time very precisely. These time measures are entirely about machines.

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

#176
post #51

Earlier quoted context omitted.

It's a minor problem. One minute off in a hundred years is something we can all live with.

Can GPS handle this? Or is it under a different time standard?

GPS has its own time thing, kinda fixed offset from TAI iirc

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

#177

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…

Arguably, being able to perform calendar calculations without leap-second information (which you don’t have for the future) is more important in applications than maintaining to-the-second accuracy over calendrical timescales.

What applications and date-time libraries should really do is differentiate between timestamps, calendar plus wall-clock time, and elapsed runtime. In most circumstances, only the latter would really need to be consistent with TAI.

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

#178
post #57
post #52

Earlier quoted context omitted.

I'm for this. Get rid of timezones, AM, PM, DST, leap years, seconds, all of it! Imagine having to know just one time. It takes a bit to wrap your head around. But only because we've accepted all the confusion for so long. The sun is still going to be "up" in one part of the world and "down" in another. The little numbers on your clock don't change that. Why can't it be the same little numbers everywhere?

How do you know whether the sun is up or down in a place when all places have the same time?

[deleted]

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

#179

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 insurance is expensive

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

#180

Earlier quoted context omitted.

The drift is sufficiently slow that you can fix it with a "leap hour" when needed -- perhaps once every five thousand years. This could be handled for civil/local time via an adjustment in the timezone definitions (something which happens a few times a year today), leaving the underlying UTC timebase unchanged.

Then let's skip the leap hour too: just let UTC and UT1 diverge up to 86400 seconds and compensate that by changing the time zones when needed. Then, when the drift reaches 86400 seconds, the clock times are aligned again. At this point we just need to re-align the dates too, and this can be done by skipping February 29 on a leap year (which should be quite easy to implement in software).

We have an implicit assumption for definitions of noon and midnight right now. I can't tell if that assumption will be there 1000 years later, but assuming that, UTC and UT1 can't really differ by much more than several hours.
Post reply on HN