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

Ask HN: How is it that programmers can simply ignore leap seconds?

news.ycombinator.com

Post reply on HN
Print view View original

21–30 of 39 posts

Re: Ask HN: How is it that programmers can simply ignore leap seconds?

#21

Post by vba616 »

sla29970 wrote: post #15

POSIX requires that we ignore leap seconds. POSIX had no alternatives to this choice because the information needed to do time right was not, and still is not, readily available via an authoritative and robust mechanism. No international recommendation has ever required the creation nor funding of a mechanism better than "This one agency in Paris will use the post office to send out letters to your national governmen…

I was under the impression that it's fundamentally impossible to determine leap seconds in the future because the rate at which the Earth is slowing down its spin varies unpredictably.

Re: Ask HN: How is it that programmers can simply ignore leap seconds?

#22

Post by sla29970 »

vba616 wrote: post #21
sla29970 wrote: post #15

POSIX requires that we ignore leap seconds. POSIX had no alternatives to this choice because the information needed to do time right was not, and still is not, readily available via an authoritative and robust mechanism. No international recommendation has ever required the creation nor funding of a mechanism better than "This one agency in Paris will use the post office to send out letters to your national governmen…

I was under the impression that it's fundamentally impossible to determine leap seconds in the future because the rate at which the Earth is slowing down its spin varies unpredictably.

At the inception of leap seconds it was unclear how well they could be predicted, but the agreement required 8 weeks of notice as a minimum. Since the inception of leap seconds the rotation of the earth has accelerated, not slowed.

Re: Ask HN: How is it that programmers can simply ignore leap seconds?

#23

Post by sla29970 »

vba616 wrote: post #20
dexwiz wrote: post #6

Computers usually report time in UTC but don't actually have leap seconds. Most computers are pretty bad at keeping time, and regularly sync to NTP servers for the current time. NTP servers generally have better time keeping hardware (or sync with better sources). When a leap second occurs, NTP servers will smear that second over 12 hours or so. Different NPT servers have different smear standards. During that smear,…

>When a leap second occurs, NTP servers will smear that second over 12 hours or so Since when? I mean that literally, I only heard of this concept recently and didn't think it was a general standard, yet.

"My system clock is wrong, what action shall I take to correct it?" Common answers to that question are "step" or "smear". The notion that the clock could be wrong is not addressed in the design of most systems, and "smear" is widely accepted as the least harmful fix.

Re: Ask HN: How is it that programmers can simply ignore leap seconds?

#24

Post by sla29970 »

sporkle-feet wrote: post #12
bartvk wrote: post #9

> If I create a date object of 1970-01-01T00:00:00 and repeatedly add 86400 seconds, should I not end up with a date/time that is no longer midnight? Of course and that’s why you shouldn’t do that. I don’t know about other languages, but if you want to advance a certain number of days, you don’t just add seconds. Any code review would pick that apart. You add (or subtract) date components, meaning you specify a day,…

If we were taking leap seconds into account, we should end up with a date/time that is not midnight. Because it does always remain midnight, it shows we are all ignoring leap seconds.

"ignoring leap seconds" is equivalent to "using a time scale that does not conform to UTC". Time scales other than UTC have 86400 seconds in a day. UTC is the exception.

Re: Ask HN: How is it that programmers can simply ignore leap seconds?

#25

Post by sla29970 »

themerone wrote: post #5
theandrewbailey wrote: post #2

I've always wondered that, too. There are fields where exact second level precision is required, but virtually everyone is OK with systems being up to a few seconds off here and there.

Leap seconds aren't a precision issue unless you need to calculate time delta's between events.

Calculating time deltas between events is fundamental for GPS navigation, tracking an incoming missile, coordinating the action of robotic systems, synchronization of telecommunications, ...

Re: Ask HN: How is it that programmers can simply ignore leap seconds?

#26

Post by bartvk »

dismantlethesun wrote: post #18
bartvk wrote: post #9

> If I create a date object of 1970-01-01T00:00:00 and repeatedly add 86400 seconds, should I not end up with a date/time that is no longer midnight? Of course and that’s why you shouldn’t do that. I don’t know about other languages, but if you want to advance a certain number of days, you don’t just add seconds. Any code review would pick that apart. You add (or subtract) date components, meaning you specify a day,…

> I don’t know about other languages... Other programming languages apart from what? You never specified which language you're talking about.

Oof I somehow butchered that. Swift.

Re: Ask HN: How is it that programmers can simply ignore leap seconds?

#27

Post by fprotthetarball »

onionisafruit wrote: post #19
zozbot234 wrote: post #16

Earlier quoted context omitted.

Use a GPS receiver, that will only get time reference and location from the GPS satellites, and not transmit anything. So you're still airgapped - see https://gpsd.gitlab.io/gpsd/gpsd-time-service-howto.html for reference.

Is it really still airgapped if it accepts input from an outside system?

No data leaves the computer over GPS and the computer controls how it processes the data. It's no worse than a keyboard.

Re: Ask HN: How is it that programmers can simply ignore leap seconds?

#29

Post by vba616 »

sla29970 wrote: post #22
vba616 wrote: post #21

Earlier quoted context omitted.

I was under the impression that it's fundamentally impossible to determine leap seconds in the future because the rate at which the Earth is slowing down its spin varies unpredictably.

At the inception of leap seconds it was unclear how well they could be predicted, but the agreement required 8 weeks of notice as a minimum. Since the inception of leap seconds the rotation of the earth has accelerated, not slowed.

>Since the inception of leap seconds the rotation of the earth has accelerated, not slowed

Ok, I'm not sure if you are correcting what I wrote or not. There is a sense in which what you write is correct, I think. But the long term trend is slowing, and since the inception of leap seconds, there have been ups and downs whether or not one averages over a year.

Illustration:

https://en.wikipedia.org/wiki/Leap_second#/media/File:Deviat...

I think this is showing that the yearly cycle is larger than the change in speed in a century, and so are the cycles in the 365-day average over decade-timescales.

Re: Ask HN: How is it that programmers can simply ignore leap seconds?

#30

Post by vba616 »

sla29970 wrote: post #23
vba616 wrote: post #20

Earlier quoted context omitted.

>When a leap second occurs, NTP servers will smear that second over 12 hours or so Since when? I mean that literally, I only heard of this concept recently and didn't think it was a general standard, yet.

"My system clock is wrong, what action shall I take to correct it?" Common answers to that question are "step" or "smear". The notion that the clock could be wrong is not addressed in the design of most systems, and "smear" is widely accepted as the least harmful fix.

Yes, I'm wondering when/how "smearing" became widely accepted, since the Wikipedia page on leap seconds only says that there is a proprietary method that Google uses, and another that Amazon uses.

"UTC-SLS was proposed as a version of UTC with linear leap smearing, but it never became standard"

Post reply on HN