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

41–50 of 96 posts

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

#41

Post by goodpoint »

Ferret7446 wrote: post #37
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.

I find it difficult to believe there are use cases affected by this; given that NTP normally has an error window of some milliseconds, those use cases would never have worked.

Wrong. The smearing cumulates during a day...

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

#43

Post by afiori »

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.

According to Wikipedia there are 27 leap seconds and obviously there is already a procedure in place to communicate new ones to the OS.

Adding them into the conversion would add O(log(#leap_seconds)) complexity.

I think that continued use of leap seconds is entirely due to inertia.

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

#44

Post by mkraft »

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

ISO 8601 was designed as a standard format for conveying date/times from the Gregorian calendar. The Gregorian calendar divides time into days, months, years which are units chosen based on Earth rotation around its axis and its orbit around the star Sol.

I don’t see why it would make sense to include points outside of Earth in that system, as I think you’re proposing.

Regarding the other part of your proposal to include locations: ISO 8601 purposely excludes those because converting a location to a UTC offset is a political process that requires lookups for historical changes to that conversion.

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

#45

Post by gpderetta »

sohkamyung wrote: post #12
fhd2 wrote: post #3

Earlier quoted context omitted.

Timestamps are used for a lot of scheduling tasks that need to be reasonably precise. So an event happening one second earlier than expected, or even twice, could be a problem I suppose. Not exactly impossible to deal with, but I guess lots of people screw it up? Haven't really worked on systems where this _truly_ matters.

Could it matter for high-frequency trading? Since these trades occur in milliseconds, I presume trading being off by a second would be considered very damaging.

It is not just very damaging, it also has legal implications. For example MIFID II regulations require at least 100us resolution for trade reporting. In practice PTP and GPS clocks are a requirement.

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

#46

Post by moffkalast »

masklinn wrote: post #28
gerikson wrote: post #8

Earlier quoted context omitted.

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.

Or one clock that can switch between 5 different times.

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

#47

Post by yakubin »

michaelt wrote: post #33
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…

> what issues does it cause for people? Five minutes - no problem at all. If the offset rose to 60 minutes, I know people complain bitterly twice a year when we change the clocks by an hour and they lose an hour of light for sports in the evening, or lose an hour of sleep. But with leapseconds taking ~0.5 seconds a year, that won't be a problem for a few thousand years.

But that’s caused by changing the clock all the time, the opposite of what PeterisP proposed. When it comes to constant offsets[1], there are countries whose political time zones are shifted from their geographical time zones by 1h (Spain, Iceland) or even 2h (Western China). It doesn’t seem to be causing problems.

[1]: Because allowing the time to drift microscopically from human perception is indistinguishable from not changing it, only that after a sufficiently long time you live in a time zone shifted by a constant, only there was never really a big event to shift it. It’s like getting old - you don’t notice it, until it’s already happened.

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

#50

Post by samwillis »

mkraft wrote: post #44
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,…

ISO 8601 was designed as a standard format for conveying date/times from the Gregorian calendar. The Gregorian calendar divides time into days, months, years which are units chosen based on Earth rotation around its axis and its orbit around the star Sol. I don’t see why it would make sense to include points outside of Earth in that system, as I think you’re proposing. Regarding the other part of your proposal to inc…

OK, so my moon landing example what slightly wrong, the Astronauts were using ET not UTC, and so we can infer that prodominatly used "human time" at that location on the moon was actually ET (what the astonougts used). And so it should be:

   1969-07-20T16:17:00!Moon/0.67416/23.47314
The point is that at that location that is the time system they were using. It's mostly a contrived example trying to make a point.

For other planetary bodies, or other locations in the universe the first part of the time stamp could use any other format that could be in use at that location. It doesn't have to be tied to an Earth centric system.

> ISO 8601 purposely excludes those because converting a location to a UTC offset is a political process that requires lookups for historical changes to that conversion

My point is we need a standardised interchange format what actually takes that into account as that is how humans actually operate.

Post reply on HN