Unix time is bad and needs replacement, not UTC
z.vandillen.dev
Unix time is bad and needs replacement, not UTC
1–10 of 96 posts
Re: Unix time is bad and needs replacement, not UTC
#2Is 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?
Re: Unix time is bad and needs replacement, not UTC
#3Is 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?
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.
Re: Unix time is bad and needs replacement, not UTC
#4Everything is bad and needs replacement :)
Re: Unix time is bad and needs replacement, not UTC
#5Can 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? Astronomy would be using specific time systems and/or adjustments anyway.
Re: Unix time is bad and needs replacement, not UTC
#6Is 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?
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.
Scheduling tasks on a system is done using UTC/local time which the system keeps accurate. Unix time is not used for that.
Re: Unix time is bad and needs replacement, not UTC
#7Large 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.
Re: Unix time is bad and needs replacement, not UTC
#8Can 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.
Re: Unix time is bad and needs replacement, not UTC
#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 time to account for them given how it's defined.
Re: Unix time is bad and needs replacement, not UTC
#10Is 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 time" (assuming there is no major changes in the solar system that would probably have such an impact on the lives of every human that nobody would care about this event anyway).