Why time may be running out for the leap second | Hacker News Reader

Why time may be running out for the leap second

economist.com

19 pointsedward25 comments

So they want to switch to what would be to de facto a non-fixed prime meridian (from time counting point of view) just because developers of time-critical systems are too lazy to use TAI or GPS time for internal time calculations...

At least for me the problem is that leap seconds are unpredictable. How many seconds are there until January 1st 2020? We don't know, nobody knows. You can only know for sure in 2019. That's bad, that's really bad. Performing internal calculations in TAI doesn't help if conversion between UTC and TAI is undefined for dates more than a year in the future.

Another way to fix the issue would be to define predictable leap seconds, just like leap years are predictable.

But I'd like to see them go. Nobody looks up to the sky and says "the sun is getting later and later". Half of the year most countries are far from solar time anyhow.

Do I care where the sun is relative to some arbitrary line in England? No.

I do like knowing when sunset is though. A second or two won't matter, but after some decades all the formulas for calculating sunset time will be wrong.

During one lifetime, you will see (at the current rate) about 60 leap seconds. Do you really notice if the sunset time is off by one minute?

Note that moving 30 km (or 20 miles) east or west also changes the sunset by one minute.

> Note that moving 30 km (or 20 miles) east or west also changes the sunset by one minute.

Depending on how close to the poles / equator you are, and probably also time of the year.

To a photographer, a few seconds of error in sunset time is the difference between an awesome sunset with oranges, reds and purples, versus an uninspiring mass of grey clouds.

Of course a photographer would start well before sunset and continue well after, but if you want to program a machine to photograph su sets you will end up having to use techniques other than checking the time.

And I'm sure we can keep that formula updated.

This being said, most computer clocks aren't so precisely accurate in the first place (especially over the course of years), and there is software (like ntp) to help keep them retuning to 'correct' time.

> too lazy to use TAI or GPS time for internal time calculations...

it's a tiny little more complicated than that.

The key element to grasp is that for all units above "second" aren't fixed: the duration of a minute, an hour, a day or a month or a year varies, depending on when it starts.

It's complicated by the fact that colloquial expectation - and likely often legally binding - is that "one day from now" is tomorrow at the same wall clock time.

So just expressing time deltas as seconds doesn't cut it, either.

This is on top of pesky details such as leap year rules (if multiple of 4 but not of hundred unless multiple of 400), half-hour time zones, and DST decided anually by parliament.

TAI and GPS - even if available - don't help you there because these things affect the algorithms and - worse - the data you need to store.

If you have a local time and forgot to store the UTC offset, you don't have a time. If you have a duration of one day, and haven't stored when this day starts, you don't know how many seconds in that day.

The particular problems of leap seconds are two: first, they are easily forgotten - leading to incorrect calculations. Second (heh!), since insertion of leap seconds is not regular, you need updates to keep your time arithmetics correct.

---

Now it might surprise you that I'd personally think leap seconds are cool, and we should keep them. However, it's hard to explain to someone faced with these problems why a few seconds of offset in sunrise time is such a big deal.

Most programmers who just read about the leap second and don't get enough information seem to miss this:

If you use time() function as POSIX defines it you already now get the "sane" number of seconds for the common calculations: to get the day after and the same time just always add 86400 seconds. It was so even at the day the last leap second happened (June 30, 2015). So the commonly used algorithms don't have to care. We already use the time as the astronomical time, add 86400 seconds and get the expected time a day after, and that there were 9e9 more oscillations of the Ce 133 atom between these two datetimes compared to other days we don't have to care.

Only if you change your system not to be POSIX compliant the calculations aren't obvious. Just don't do it.

The system as it is now, with the leap seconds happening, works. Who needs to care about TAI already cares. No need changing it.

http://www.wired.com/2015/01/torvalds_leapsecond/

"You’d have to teach people to not care about the correlation of time to the sun, or the correlation of dates to the seasons. That doesn’t sound very realistic.

The people and computers who really care about “atomic” time tend to be astronomers. For the rest of us – both people and computers – we’re probably better off taking the POSIX approach to it, and just say “who cares”, with a few unlucky people worrying about bugs happening because of the perversities of timekeeping."

I don't really get what the proposed alternative is here. To just let the time of day drift away from the time on the clock?

Then way not abolish leap years as well?

Just let it drift, yes, I assume.

Then maybe in a few thousand years when we're a full hour out we can think about having a leap hour.

Abolishing leap years, on the other hand, would cause the calendar to shift relative to the seasons by a notable amount during your lifetime.

> Then maybe in a few thousand years when we're a full hour out we can think about having a leap hour.

If we even care, at that point. We might well have switched time keeping systems several times by then, seen massive improvements in artificial lighting and heating and such.

I think that's the general idea of "what's the point of leap seconds". By the time they actually matter, we're not sure they matter anymore.

Leap years run into a similar issue that the ratio of days to years is changing as well. Our current algorithm will eventually be off. No one cares because the people doing time standards will be long dead.

And arguably the situation is similar for leap seconds as well. No one cares because of how far out substantial drift is. By the time it adds up to an hour, people will be used to it, or just shift their timezones (which happens all the time).

Leap years are regular, leap seconds are not. Skipping leap day would be earlier and more obviously noticable than skipping leap seconds.

> Then way not abolish leap years as well?

Religion.

For example, the various Christian groups want to keep Easter at the Correct Time each year, and the leap year is part of the complex calculations they use to accomplish that.

https://en.wikipedia.org/wiki/Computus It really is a bit involved.

I suppose they could redo everything to accommodate a calendar without a leap day, but the Julian to Gregorian update was divisive enough, and you really expect them to go through all that again so soon?

More to the point, calendars are more deeply embedded in the culture than things like TAI and UTC and so on. Changing a calendar is a maybe-once-in-a-millennia event.

Perhaps we could adjust leap seconds once every 10 or 15 years. A 5 second change is unlikely to be disruptive if there is a common, semirare schedule.

That would be worse since most likely every single machine will fail - if it's not common no one will think to test or implement it.

And a many-second jump is harder for the computer to handle smoothly, especially if it's a backward jump.

It's not a backward jump – you just let the clock run a bit slower for a minute, or an hour, or whatever. Smearing the second out works for 99% of people/computers, and when it doesn't you probably have much bigger problems keeping your clocks in sync anyway, so you should be able to handle a few leap seconds too.

This seems like a natural progression to me. When the rotation of the earth was the most accurate period available then it made sense to use that as a reference. Now it is not and it doesn't.

I think that in the future people will just use UT for anything where people have to coordinate activities. We can have a separate time scale for things we want to coordinate relative to sunrise and sunset. This scale will be able to be completely accurate based on location so we would abolish stupid stuff line time zones and DST. The result will be much simpler.

The very concept of a leap second is flawed. Given two times (say T1 and T2) we need to be able to compute, accurately, the elapsed time. Time series data becomes difficult to interpret accurately.

We should abolish DST while we are at it.

Yes we should, but it has nothing to do with this. DST is a local thing (state/province level), leap seconds are worldwide.

I like having more sun-filled evening time.

I think the idea is that we'd achieve the same effect by changing working hours. There's nothing sacred about 9-5. If you're dealing with people in different timezones, you need to know the offset of your timezones, and take DST into account. If this were changed, you'd need to know the offset of your timezones, and take local working hours into account.

The benefit is not having to upgrade all the numerous specialised systems that may or may not be supported anymore every time a politician decides to change the clock. Having to throw out or hack around timekeeping problems with outdated-but-working embedded equipment carries costs.

(This discussion is of course completely tangential to the article)

Reply on news.ycombinator.com