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

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

nature.com

Post reply on HN
Print view View original

251–260 of 456 posts

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

#251

Post by divbzero »

hoytech wrote: post #103

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…

This is a good story regardless, but if you do want to derive some morals from the experience:

– Seemingly simple tasks can be more complex than you expect (“add a leap second on this Wednesday”)

– Real world systems can be more complex than you expect (“bunch of software I never even knew existed”)

– Planning and testing can make a big difference vs. just winging it (“a bunch of our Linux servers had kernel panics for some reason”)

– Success can be a non-event that goes unnoticed (”everything worked and no money went missing”)

– Sometimes the best solution is not a technical solution (“halt the markets for 15 minutes before/after”)

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

#252

Post by krick »

toast0 wrote: post #191
krick wrote: post #166

Earlier quoted context omitted.

I'm not sure I support your "hot take" — it is hot and requires a lot of contemplation. But that's not the point, IMO. The point is, that there ALREADY EXIST both TAI and UTC. TAI is true monotonic (whatever it means in a relativistic universe) and doesn't make any compromises. UTC abolishes monotonicity in order to keep both the length of a second and the time relationship to the orbital rotation. They both work. Fo…

> For whatever reason (for obvious reasons that is, but doesn't matter) UTC was chosen in virtually any software system to keep time. What was chosen really isn't UTC. Several UTC seconds in the past are not accurately representable in unixtime. Several unixtime seconds in the past are ambigious as to which UTC second they are. Unixtime is awfully close to UTC time, but it's not the same. If UTC time stops inserting…

Not really. I mean, it's true that we should distinguish between the 2 and everything that you said about the difference is also true. But unixtime doesn't really "exist" in a sense UTC and TAI do. It is rather an imperfect implementation of UTC, that chooses to ignore (or repeat) some seconds.

You can hear that unixtime is the number of seconds passed since X. But it isn't really true though. The number of seconds is number of seconds, it isn't defined by our standards, it just exists. And TAI is a fair representation of how many seconds on Earth actually passed (on average) since whatever.

UTC kinda does it as well by virtue of 1 second being equal to 1 TAI second, but it actually counts (counted until yesterday) the number of Earth's rotations. It's just every rotation (represented by 24H) sometimes consists of more than 86 400 seconds.

Unixtime on each individual device counts nothing. It imperfectly represents UTC timestamp received over NTP. Some timestamps are represented twice by the same value. Of course, you can just put your device offline and call it "unixtime" whatever number of seconds it counts since any moment, but you know it will drift away from any meaningful "real" time soon enough.

(Also, it's not even entirely fair to say, as you did, that it is unixtime that was chosen by all the software. Many programs store datetimes as strings. Usually, they still don't support "23:59:60" anyway, but that doesn't really make them unixtime. Unixtime is a timestamp encoding.)

So, that's basically what I'm talking about: you can just make unixtime an implementation of TAI (as opposed to UTC). You can build a new calendar format for it, introduce a new name (not UTC!) for it and see how well it does when all the world slowly drift from Earth's rotation to keep up with TAI. Maybe it actually is fine, I'm not a judge for it (because it really is complicated and I didn't decide yet if it's a good solution or not). But why the fuck would you destroy UTC for it?! It is a closest usable representation of UT1, which doesn't stop to exist! Leave it be!

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

#253

Post by dpkirchner »

hoytech wrote: post #103

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…

The moral is that sometimes we humans can choose not to let the perfect be the enemy of the good (enough).

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

#254

Post by worik »

techdragon wrote: post #80

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…

> Storing anything as UTC was a mistake and we should be using TAI

I had to look up TAI. I disagree. UTC exists for a reason. But I am here to tell a war story.

Before I arrived on the scene a customer said they wanted local time in the reports. (As in Wall Clock Time).

The Customer is Always Right. OK?

So the times went into the database as wall clock time.

The designers of the data schema made a simplifying decision to store everything as text.

No time zone went into the text string that described the time. (?? I do not know why. So easy it would have been)

I come along and have to code animations using that time series data.

Very few problems...

As you would expect there are a lot of other problems with that database.

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

#255

Post by red_trumpet »

techdragon wrote: post #80

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…

> we should be using TAI for all [...] computation

How do you add a full day, if you do not know whether a leap second occured or not?

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

#256

Post by deathanatos »

brazzy wrote: post #156
zokier wrote: post #127

Earlier quoted context omitted.

I'm pretty sure UTC is monotonic too, its unix timestamps that really are the true mess

Wrong. The very topic of this discussion, leap seconds, are non-monotonic adjustments to UTC.

UTC is monotonic, even during leap seconds. (A positive leap second adds a 23:59:60; no timestamp ever repeats, the clock never moves backwards.)

(Negative leap seconds are similar, and do not affect the monotonic property.)

POSIX/Unix timestamps, however, are non-monotonic. But that's a different timescale.

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

#257

Post by kevinventullo »

worik wrote: post #245
jimmaswell wrote: post #190

Earlier quoted context omitted.

Think of all the time that could be better appropriated than on fintech in general. Seems like such a waste of resources siccing a bunch of computers against each other in a zero sum game of stock arbitrage. I will admit some of the stuff tech comes out of it is cool on its own at least.

> Seems like such a waste of resources siccing a bunch of computers against each other in a zero sum game of stock arbitrage Despite the useful service of price discovery (here are so many better ways) it is clear from the EMH that those computers are not doing arbitrage, they are front running trades. Illegal. Criminal in USA (I think). But makes billions and billions for the already very rich. So that is why there…

Someone has to make the EMH hold.

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

#259

Post by yreg »

divbzero wrote: post #251
hoytech wrote: post #103

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…

This is a good story regardless, but if you do want to derive some morals from the experience: – Seemingly simple tasks can be more complex than you expect (“add a leap second on this Wednesday”) – Real world systems can be more complex than you expect (“bunch of software I never even knew existed”) – Planning and testing can make a big difference vs. just winging it (“a bunch of our Linux servers had kernel panics f…

>Sometimes the best solution is not a technical solution (“halt the markets for 15 minutes before/after”)

We've had an election recently, right on the day when DST changed. On the night of counting of the votes, the clock went 2:59 AM -> 2:00 AM.

To save themselves trouble the Statistics Office instructed all vote counters that under no circumstances are they to enter or update anything in any system during the repeating hour until it's 3:00 AM the second time…

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

#260

Post by deathanatos »

ender341341 wrote: post #89
jylam wrote: post #59

It seems I've got an unpopular opinion reading the comments here, but having some leap seconds from time to time ensure we are able to manage them. But "no leap second should be added for at least a century" ensures there will be a y2k reckoning every century. Seems short sighted to me, even if it is not a game-changing issue, let's be honest.

Why have them at all? how many people do things where they actually matter? at the current rate it'll be ~9000ad before we hit an hour offset, and we do hour offsets twice a year, so if an hour off is okay why is 1 second off not?

And that timescale is called TAI. It's always been an option, but for whatever reason, people (and standards) (collectively) use UTC but want it to act like TAI.
Post reply on HN