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

31–39 of 39 posts

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

#31

Post by matthewmacleod »

zozbot234 wrote: post #16
staticautomatic wrote: post #14

Earlier quoted context omitted.

How can air-gapped computers keep time well?

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.

It's not really an air-gapped system if it accepts unauthenticated external radio signals and changes state in response, which is what would be happening in that case.

You don't need much imagination to think of various attacks that a spoofed GPS signal could open up, if you were able to cause a system to have an incorrect time.

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

#32

Post by scaramanga »

> Since 1970, there have been 27 leap seconds applied. But these don't show up anywhere in any computer system I have ever used (OS, languages, applications, third party APIs). 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?

The timestamp on your computer is is in a timescale (called UNIX time) which is defined as not including leap-seconds, so no. The advantage of this system is that there is an algorithm for converting the integers to points on a calendar and back again. Kinda as you mentioned (ie. just keep adding 86400 to go forward a year, a bit more if it's a leap year, etc.). The downside is that you can set your timestamp integer to some value and it can refer to a second in UTC which happened twice (like those 27 leap seconds), or not at all (if a negative leap second is inserted in the future).

If you want to use UTC as your timescale, then you would have a different representation (something like TAI) and you would need to know about leap-seconds in order to do the integer-to-calendar-or-back-again type of calculations.

As with all things in engineering, it is a trade-off and what is the best choice depends very much on what you are trying to do.

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

#33

Post by sla29970 »

vba616 wrote: post #29
sla29970 wrote: post #22

Earlier quoted context omitted.

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#/me…

Look at the past 250 years where there is not really any clear indication of deceleration https://www.ucolick.org/~sla/leapsecs/dutc.html

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

#34

Post by sla29970 »

sporkle-feet wrote: post #13
908B64B197 wrote: post #11

> including applications that require a certain level of accuracy (e.g. processing pricing feeds from financial institutions) Should leap seconds matter then? As long as you are synchronizing with the same source of truth as the financial institution's back-end, both clocks should tell the same time.

What if we're trying to correlate prices from two different financial institutions? Maybe one uses smearing and one doesn't, who knows?

In that case UTC is the wrong answer to the question "What timescale will produce robust results for this application?" As soon as leap seconds were recommended by the CCIR in 1970 radionavigation system administrators announced they would switch to purely atomic TAI-10s and astronomical almanacs continued to use just plain UT. Proceedings of international standards bodies show them discussing how the new CCIR timescale with leap seconds (not yet officially named UTC) need not apply to anything other than radio broadcast time signals.

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

#35

Post by omegalulw »

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,…

Why can't we just switch to TAI for computers and anything electronic everywhere and just use UTC for user visible timestamps?

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

#36

Post by sla29970 »

vba616 wrote: post #30
sla29970 wrote: post #23

Earlier quoted context omitted.

"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"

Lack of agreement; "smearing" is completely normal for answering "What time is it?", and completely wrong for applications requiring precise time.

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

#37

Post by vba616 »

sla29970 wrote: post #33
vba616 wrote: post #29

Earlier quoted context omitted.

>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#/me…

Look at the past 250 years where there is not really any clear indication of deceleration https://www.ucolick.org/~sla/leapsecs/dutc.html

It says "Over the passage of centuries the rotation of the earth is being decelerated by tidal friction from the moon and sun"

Are you correcting me, or not, or what is it you are trying to communicate?

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

#38

Post by sla29970 »

vba616 wrote: post #37
sla29970 wrote: post #33

Earlier quoted context omitted.

Look at the past 250 years where there is not really any clear indication of deceleration https://www.ucolick.org/~sla/leapsecs/dutc.html

It says "Over the passage of centuries the rotation of the earth is being decelerated by tidal friction from the moon and sun" Are you correcting me, or not, or what is it you are trying to communicate?

It is possible 8 weeks in advance to predict the difference between UTC and UT1 and keep it less than 0.9 seconds. Nothing more is required by international agreement.

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

#39

Post by stephenr »

jamjamjamjamjam wrote: post #17

A real shitstorm is going to happen in 2038 when unix time overflows. I base this hypothesis on how slow moving the industry is recently

What critical systems are actively in use now that still use a signed 32bit `time_t` or equivalent?
Post reply on HN