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

Leap second hiatus

fanf.dreamwidth.org

Post reply on HN
Print view View original

111–117 of 117 posts

Re: Leap second hiatus

#111

Post by kqr »

wmf wrote: post #14
kqr wrote: post #13

Earlier quoted context omitted.

Why is this downvoted? It sounds great to my untrained ear. You could even use TAI for user-facing timestamps (to get consistent arithmetic) and then convert to UTC only in the end before displaying the date!

You know in some places they will forget the conversion so you'll have weird cases that are off by 37 seconds.

Surely that's

a) Discovered sooner than a leap year bug, and b) Given that humans and not machines are the consumers of the UTC time, less consequential than a leap year bug.

Re: Leap second hiatus

#112

Post by sla29970 »

zokier wrote: post #51
bhk wrote: post #27

Earlier quoted context omitted.

Leap seconds have nothing to do with precision time. It's a non-periodic alteration to the definition of UTC. Those niche applications that require second-accurate knowledge of Earth's rotational accuracy don't need to rely on leap second changes to UTC; they could get that information out of band, and will need to anyway when they need sub-second accuracy. The 99.999% of other applications that don't need to know Ea…

> Leap seconds were a terribly misguided idea. I prefer dropping leap seconds, but I wouldn't call them misguided. UTC and leap seconds come from maritime celestial navigation, where tracking rotation is actually important. Civil time then just piggybacked on that, which at the time probably was perfectly reasonable solution.

A detailed look at the negotiations that led to leap seconds shows that they were not for maritime celestial navigation. During the process several different times the celestial navigation folks set a limit on how far radio broadcast time signals could deviate from astronomical time, and every one of those limits was violated as the negotiations proceeded. By the time the draft recommendation was given to 12th Plenary Assembly of the CCIR it allowed for leaps of multiple seconds, and that draft was amended on the floor to leaps of only one second before they voted to approve.

Re: Leap second hiatus

#113

Post by gerikson »

btilly wrote: post #109
gerikson wrote: post #107

Earlier quoted context omitted.

Why not derive UTC from TAI (via a table of leap seconds)? Then apply the TZ rules to DST to arrive at local time.

The short answer is that I don't do this because I'm not insane. Think about it. How much software would I have to rewrite to make this possible? What value does that rewrite create? And will maintenance programmers thank me for it? Will it get adopted? As a programmer I have to interact with databases, operating systems, various libraries in various languages, and so on. Frequently with quick switching between them.…

I feel the solution is for the programming community to slowly and methodically move towards using TAI in basic infrastructure (operating systems, routers, NTP etc) and build a base on which to derive the civil timekeeping (UTC + localtime, DST etc).

That, or get involved in the standards work. That said, after ruining observations by sending a bunch of satellites into space, tech people might be even less popular than before in the astro community...

Edit I just got around to reading that Wired article and... ugh

> Reddit was just one of several web outfits that were hit by leap second glitches just after midnight Greenwich Mean Time on Saturday,

Article is from Jul 2012, GMT was not in effect at that time. I guess they meant UTC, but if tech journalists don't know that GMT is depreciated as a concept of "universal time" what hope is there for meaningful time reform...

Re: Leap second hiatus

#114

Post by throw0101a »

Tepix wrote: post #34

Just because everyone seems to be complaining about leap seconds: I think they are the right solution for the problem. I do hope we won't need a negative leap second, that would break a lot of code for sure. Time related stuff sure is messy.

> I do hope we won't need a negative leap second, that would break a lot of code for sure.

Someone ended up asking on one of the FreeBSD mailing lists, and it seems that they test for it:

* https://lists.freebsd.org/pipermail/freebsd-stable/2020-Nove...

So at least when it comes to the FreeBSD kernel and ntpd, there's nothing to worry about there. Userland code may be a different matter of course.

Re: Leap second hiatus

#115

Post by btilly »

gerikson wrote: post #113
btilly wrote: post #109

Earlier quoted context omitted.

The short answer is that I don't do this because I'm not insane. Think about it. How much software would I have to rewrite to make this possible? What value does that rewrite create? And will maintenance programmers thank me for it? Will it get adopted? As a programmer I have to interact with databases, operating systems, various libraries in various languages, and so on. Frequently with quick switching between them.…

I feel the solution is for the programming community to slowly and methodically move towards using TAI in basic infrastructure (operating systems, routers, NTP etc) and build a base on which to derive the civil timekeeping (UTC + localtime, DST etc). That, or get involved in the standards work. That said, after ruining observations by sending a bunch of satellites into space, tech people might be even less popular th…

Do you have any idea how much work it is to rewrite all of that software?

The solution people are actually moving to is https://developers.google.com/time/smear. The downside is that measurements of elapsed time will be off in that day. But no rewrite needed, and most applications are going to be just fine with that.

Article is from Jul 2012, GMT was not in effect at that time. I guess they meant UTC, but if tech journalists don't know that GMT is depreciated as a concept of "universal time" what hope is there for meaningful time reform...

Timezones may have multiple names. Greenwich Mean Time and Zulu, aka GMT and Z, are officially defined timezones that happen to be UTC+0. Both are in widespread use and are not wrong.

Re: Leap second hiatus

#116

Post by centimeter »

lifthrasiir wrote: post #105
centimeter wrote: post #104

Earlier quoted context omitted.

Using TAI is simpler because: * Many apps can get away with only using TAI, so they don't necessarily have to track the difference between UTC and TAI * If your system uses TAI in its distributed coordination mechanisms, you don't need to worry about leap seconds and an error in the UTC-TAI difference won't cause your system to fail

> Many apps can get away with only using TAI, so they don't necessarily have to track the difference between UTC and TAI Most systems don't need to keep the difference between UTC and TAI to display the UTC time anyway. TAI matters when you have to manipulate the non-zoned wall clock (as opposed to date and time components) and that's surprisingly rare. > If your system uses TAI in its distributed coordination mechan…

Yeah, you're right that the primary benefit of TAI is that it's monotonic - but it's better to have a globally consistent monotonic schelling point than to deal with every machine having its own detached monotonic clock.

> GPS clock

GPS and TAI are essentially the same, modulo a fixed 19 second offset.

Re: Leap second hiatus

#117

Post by gerikson »

btilly wrote: post #115
gerikson wrote: post #113

Earlier quoted context omitted.

I feel the solution is for the programming community to slowly and methodically move towards using TAI in basic infrastructure (operating systems, routers, NTP etc) and build a base on which to derive the civil timekeeping (UTC + localtime, DST etc). That, or get involved in the standards work. That said, after ruining observations by sending a bunch of satellites into space, tech people might be even less popular th…

Do you have any idea how much work it is to rewrite all of that software? The solution people are actually moving to is https://developers.google.com/time/smear . The downside is that measurements of elapsed time will be off in that day. But no rewrite needed, and most applications are going to be just fine with that. Article is from Jul 2012, GMT was not in effect at that time. I guess they meant UTC, but if tech jo…

There’s an ambiguity in that GMT is a civil timezone that in the UK is BST when DST is in effect. UTC cannot be affected by DST.

I hear a lot of Brits calling their time “GMT” even when DST is in effect. It’s a shorthand for “current time in the UK”. Hence, ambiguous.

Post reply on HN