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

Unix time is bad and needs replacement, not UTC

z.vandillen.dev

Post reply on HN
Print view View original

81–90 of 96 posts

Re: Unix time is bad and needs replacement, not UTC

#81

Post by zowie_vd »

beeforpork wrote: post #68

These are 'interesting', but ultimately naive ideas, and the headline is presumptuous. Instead, the world needs agreement. And, wow!, an agreement among countries to simplify time keeping is an achievement! We do not need a more complex POSIX time spec, but we need to cope with billions of written lines of code from the past that use the existing API. We need that API to be as stable as possible to reduce complexity.…

Thank you for your opinions. The point of my proposal was to keep the API entirely backwards compatible, so rewrites would not be necessary. The important part is the "Legacy Unix Time" part. The other two definitions I provided simply serve that definition. I hope that you will agree that this is not that much more complicated.

Notably I don't disagree with the idea of abolishing leap seconds, but I also don't think it's entirely agreeable to have the world's timekeeping standards changed solely because of engineering needs with regards to Unix time. In my opinion it's somewhat silly to have the timekeeping standard of the world changed because someone at Bell labs made an unfortunate design decision regarding Unix time, rather than changing Unix time itself.

Re: Unix time is bad and needs replacement, not UTC

#82

Post by zowie_vd »

PeterisP wrote: post #5

Can someone comment on the practical usefulness of having UTC stay strictly synchronized with the rotation of the Earth? Intuitively it should be synchronized, but giving it more thought it is not entirely obvious why; e.g. my current local time zone is more than half an hour off of local solar time, and that isn't really a practical problem, so if UTC would be, say, five minutes off of actual solar time in Greenwich…

I don't think there is a practical need for UTC to be synchronized with the rotation of the Earth for a long time, because although the error accumulates, it only accumulates very slowly. That being said, it's unclear how people would solve the problems that will arise once that long time has passed. In any case, although it's probably too late for leap seconds, untying the definition of Unix time from UTC would allow astronomers to decide with more freedom what the future of UTC is going to be.

Re: Unix time is bad and needs replacement, not UTC

#83

Post by karmakaze »

samwillis wrote: post #24

This is a good article, it's worth reading in full. It touches on the different use cases for different types of time/date storage but doesn't make it explicit enough that the is no "one size fits all" solution. It's true that internally a TIA timestamp is cleaner for storing a moment in time, but that is only half the issue. I like to think of it as a difference between physical time and human time. For engineering,…

Different than the UTC/TAI issue: A limitation of only using UTC timestamps came up when I worked at a social photo sharing company. We needed to define how to store and transport them, and everyone was saying UTC is the answer and I was arguing for local time + TZ and/or location.

The example I used was if New Years pictures were posted by a photographer in say New Zealand that was being viewed by someone in the US. Showing the US local time for that photo doesn't indicate how many minutes before or after midnight the photo was actually taken. For data transfer, ended up using strings for local date/time and location to ensure that nothing tried to interpret and transform unless explicitly intended.

Re: Unix time is bad and needs replacement, not UTC

#84

Post by rand_flip_bit »

zowie_vd wrote: post #25
jesprenj wrote: post #17

EDIT: This comment was corrected by numerous replies below and the original comment contained incorrect information. Thanks to all posters for the corrections. Original comment: > The simplified definition of Unix time is that Unix time counts the amount of seconds that have passed since the first of January 1970 (which is referred to as “the epoch”, similar to the first of January of 1 AD being the epoch of the Greg…

In short, Unix time is based on UTC. If there's a leap second at midnight, you start a stopwatch ten seconds before midnight and stop it ten seconds after, then there is going to be a one second difference between your stopwatch and the difference between the Unix time timestamps of the moments you started and stopped the stopwatch.

For the purposes of a stopwatch/timer, this is exactly what you want. A measurement of time that is exact and does not include leap seconds. Accounting for DST or leap seconds or any other changes to the local timezone for that matter would be disastrous. Imagine you are trying to bake a cake and the timer doesn’t go off for an extra hour due to the clocks getting set back. Now you just have a ruined cake :(

As far as Unix and UTC are concerned, many systems provide the option to smear the system clock over a 24h period (-12h, +12h) centered on the leap second. This avoids the discontinuity and can help avoid errors some incorrectly written programs may not be able to tolerate.

For leap smearing, see: https://developers.google.com/time/smear

Re: Unix time is bad and needs replacement, not UTC

#85

Post by denton-scratch »

Nullabillity wrote: post #80
denton-scratch wrote: post #59

I hope that, when they redefine UTC, they define a new name for it. UTC has been the same timescale since it started; the history of redefinitions of GMT is a horror-story. I guess what I'm really saying is that UTC-without-LS won't be UTC; rather, we'd declare that the new universal civil-time timescale is to be UTC-without-LS. You could carry on computing old-fashioned UTC after the transition; but one wouldn't gen…

This is effectively just an agreement to _stop_ redefining UTC every couple of years.

Leap-seconds are a fundamental part of the definition of UTC. Declaring a leap-second doesn't amount to declaring a new timescale. Abolishing the leap-second, however, does declare a new timescale.

Re: Unix time is bad and needs replacement, not UTC

#86

Post by denton-scratch »

sgtnoodle wrote: post #75
denton-scratch wrote: post #59

I hope that, when they redefine UTC, they define a new name for it. UTC has been the same timescale since it started; the history of redefinitions of GMT is a horror-story. I guess what I'm really saying is that UTC-without-LS won't be UTC; rather, we'd declare that the new universal civil-time timescale is to be UTC-without-LS. You could carry on computing old-fashioned UTC after the transition; but one wouldn't gen…

Leap seconds are determined manually, though, so it seems like there's no practical difference other than UTC's error from solar time going out of spec?

> other than UTC's error from solar time going out of spec?

Well, yeah. Except that if it's not in-spec, it's not UTC; it's something else, and it shouldn't be called UTC. If you don't change the name, you would end up unable to compare two UTC times without also knowing which version of UTC the two times were given in.

Re: Unix time is bad and needs replacement, not UTC

#87

Post by beeforpork »

zowie_vd wrote: post #81
beeforpork wrote: post #68

These are 'interesting', but ultimately naive ideas, and the headline is presumptuous. Instead, the world needs agreement. And, wow!, an agreement among countries to simplify time keeping is an achievement! We do not need a more complex POSIX time spec, but we need to cope with billions of written lines of code from the past that use the existing API. We need that API to be as stable as possible to reduce complexity.…

Thank you for your opinions. The point of my proposal was to keep the API entirely backwards compatible, so rewrites would not be necessary. The important part is the "Legacy Unix Time" part. The other two definitions I provided simply serve that definition. I hope that you will agree that this is not that much more complicated. Notably I don't disagree with the idea of abolishing leap seconds, but I also don't think…

> I hope that you will agree that this is not that much more complicated.

Sorry, but I do not agree. The current Unix time API is good enough. Especially with the leap seconds gone. We need no more complication by innovation here.

Any extensions inevitable lead to a lot of people starting to use those additional APIs, others trying to fix old code to use new APIs, and a few will start religiously fighting for the use of the new 'right' API. Software that handles time would be more diverse. And you will never live to see that old API gone anyway, because we don't know where it hides, so in the future, we would have to deal with bugs in the (mis)usage of more APIs.

> In my opinion it's somewhat silly to have the timekeeping standard of the world changed because someone at Bell labs made an unfortunate design decision regarding Unix time, rather than changing Unix time itself.

Well, maybe it is silly. But that's really irrelevant. Don't be stubborn to insist on API changes/extensions, because you think a past decision was wrong. You can't change reality anyway: the vastly bigger problem is changing Unix time, because code is written and is running in critical systems.

And because leap seconds were inserted manually anyway, we already have a solution that works: don't insert any more leap second manually.

Also note that the danger was to do something new: remove a second. That is a very dangerous experiment. E.g., the German DCF77 cannot even announce that (I think the UK and US time signals can, IIRC -- I am not sure about Japan and the other time signals). Of course you could start to postulate we need a new time signal format in Germany (and effectively half of Europe) to fix that, but that is just a much more dangerous approach.

Re: Unix time is bad and needs replacement, not UTC

#88

Post by sllabres »

zowie_vd wrote: post #21
ZiiS wrote: post #7

Large cloud providers smear time. A day containing a leap second has the normal number of Unixtime "seconds" but each is 1/86400 too long. The inaccuracy this introduces is relevant to such a tiny tiny percentage of use cases; who already have to deal with the extreme complexities of time at this accuracy that everyone wins.

Large cloud providers are actually exactly the ones who argued that leap seconds should be abolished, so I presume there were enough use cases where this was an issue. I faintly remember one article about the announcement of the voting results where they talked about the issues that smearing could cause but I don't remember exactly what it was, or where I read it.

Voting running after midnight local time (where leap seconds get inserted) and dependent on sub-seconds, with only five leap seconds since 2000 introduced reads like a really interesting case.

Re: Unix time is bad and needs replacement, not UTC

#89

Post by sllabres »

shpx wrote: post #62

If we’re going to change the timestamp let’s do it correctly this time and start counting from 0001-01-01 (like “ticks” in C#) or 0000-01-01 because adding another number (1970) for other people to have to learn about and memorize is bad design and unnecessary overhead and one subgroup of one profession naming a whole time epoch was kind of pretentious. It would also have the added benefit of being hard to confuse a…

You know, that they used a different calendar back then, right?

Re: Unix time is bad and needs replacement, not UTC

#90

Post by sgtnoodle »

denton-scratch wrote: post #86
sgtnoodle wrote: post #75

Earlier quoted context omitted.

Leap seconds are determined manually, though, so it seems like there's no practical difference other than UTC's error from solar time going out of spec?

> other than UTC's error from solar time going out of spec? Well, yeah. Except that if it's not in-spec, it's not UTC; it's something else, and it shouldn't be called UTC. If you don't change the name, you would end up unable to compare two UTC times without also knowing which version of UTC the two times were given in.

I don't follow. UTC with no more leap second updates isn't a new version. It's the same timebase, just without any future updates to the leap second table. If the folk that maintain UTC decide to stop adding or subtracting leap seconds, it's not a fork in the timebase.

That fork already happened with TAI. TAI was the same as universal time in 1958, and has progressed without any leap seconds. The current offset between TAI and UTC is 37 seconds. We could all agree to switch unix time to TAI, but there would be a 37 second discontinuity.

I currently work on autonomous aircraft, and we use GPS time internally for avionics. The monotonicity is very nice for correctness when developing real time code. Outside of avionics, it's very confusing for people that tend to work in UTC. I've written table based timebase converters a few times now.

Post reply on HN