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

21–30 of 96 posts

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

#21

Post by zowie_vd »

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.

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

#22

Post by account42 »

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…

Your understanding of Unix time is wrong. In your experiment the difference between the end and start Unix timestamps would be 7200 even though thats off from the experiment duration. That is exactly the problem: Unix time gets adjusted for leap seconds to stay in sync with UTC instead of real time.

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

#23

Post by masklinn »

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…

> As far as I understand it, that's what UNIX time is

Then you don’t understand Unix time. In the first case it would return 7200, and in the second case it would count “made up time”.

UNIX time is 86400*days since epoch + seconds since midnight. It does not measure “real time”, whatever that is.

> Leap seconds never happened, they were added to UTC and UTC only in order to correct it for sunrise and sunset.

You’re apparently confusing leap seconds and DST. Leap seconds are used to compensate for minute variations in the speed at which the earth rotates (irregularities and an overall slowdown). So they serve to resynchronize atomic time (TAI) and solar time (UT1). This resynchronized version (UT1 ~ 1s) is UTC.

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

#24

Post by samwillis »

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, science, precise measurement, simulation and such using TAI is clearly the cleaner, most robust solution. But as soon as you have a humans "perception" of time as part of the system a timezone aware timestamp is required. But even then, the most common version of that ISO 8601 is flawed.

ISO 8601 only has a fixed offset, it has no concept of timezones or geolocation. Borders between timezones move, DST windows change or disappear, it has no way to account for that. What we need is an extended ISO 8601 that includes a location rather than offset. Human time is tied to a geographic location in time. I think we need something like this:

  2022-11-23T08:52:02!Europe/London
using the names from the TZ database: https://en.wikipedia.org/wiki/List_of_tz_database_time_zones

or even coordinates:

  2022-11-23T08:52:02!51.509865/-0.118092
we probably even want planetary body:

  1969-07-20T20:17:00!Moon/0.67416/23.47314
This is the only way to store "human time" in a future proof way.

Physical moment in time = TAI timestamp

Human perception of a moment in time = Geolocated timestamp

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

#25

Post by zowie_vd »

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.

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

#26

Post by DemocracyFTW2 »

Cu3PO42 wrote: post #14
Tenoke wrote: post #9

>The exact way Unix time handles leap seconds* is complex and an unnecessary detail for this article, but it will suffice to say that (i) whenever a positive leap second occurs, a timestamp is used twice, and (ii) if a negative leap second were to occur, a timestamp is skipped. Huh, I always assumed that Unix time just ignores them and ticks forward. I get why e.g. UTC needs them but why would it make sense for Unix…

If Unix time ignored them, the conversion between timestamps and UTC would no longer be possible with just arithmetic operations. You'd need a list of leap seconds and take them into account. Now one can argue if this is better or worse than the current solution, but it's not without its tradeoffs.

I'd argue that a very short and rather simple and infrequently changing list of delta seconds (which are only ever applicable around 23:59:59, December 31 of some years) is vastly preferable over any other of the solutions (or rather 'coping strategies' as it were) that are used now, things like Google and Amazon smearing their leap seconds but in ever so slightly incompatible ways.

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

#27

Post by masklinn »

jesprenj wrote: post #18
Cu3PO42 wrote: post #14

Earlier quoted context omitted.

If Unix time ignored them, the conversion between timestamps and UTC would no longer be possible with just arithmetic operations. You'd need a list of leap seconds and take them into account. Now one can argue if this is better or worse than the current solution, but it's not without its tradeoffs.

Edit: My original comment is incorrect. Please read child comments. Original comment: Yes, to convert from UNIX time to UTC, you do need a list of leap seconds.

No. You need a list of leap seconds to convert from Unix time to TAI.

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

#28

Post by masklinn »

gerikson wrote: post #8
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 see leap seconds as regulatory capture by astronomers :D Basically it's convenient for them to have civil time (UTC) never more than 0.5s from UT1.

Astronomers don’t care, they already need like 5 different clocks.

Also the allowable variance between UTC and ut1 is 0.9.

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

#29

Post by qbrass »

Tenoke wrote: post #9

>The exact way Unix time handles leap seconds* is complex and an unnecessary detail for this article, but it will suffice to say that (i) whenever a positive leap second occurs, a timestamp is used twice, and (ii) if a negative leap second were to occur, a timestamp is skipped. Huh, I always assumed that Unix time just ignores them and ticks forward. I get why e.g. UTC needs them but why would it make sense for Unix…

It's usually set up to sync to NTP.

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

#30

Post by account42 »

globular-toast wrote: post #10
rapsey wrote: post #2

Is it not irrelevant for most use cases? Leap seconds or whatever. Think of the time of this post. It is stored but how important is the accuracy?

That was my thought when considering the difficult and impossible tasks of converting to/from UTC-based timestamps. If we accept that UTC is only for human use then we should also accept that humans can't tell the time of day down to the second just based on their circadian rhythm and the Sun. Given a TAI-based timestamp a hundred years in the future we can be pretty certain in saying "yeah it will be around lunch ti…

But if you follow that argument then you might as well drop leap secnds from UTC (which also drops them from Unix time). Which is what was done. So computers can have nice math and conversions to UTC are not needlessly complicated for little benefit to humans.
Post reply on HN