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

61–70 of 96 posts

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

#61

Post by lodovic »

nirimda wrote: post #55
samwillis wrote: post #40

Earlier quoted context omitted.

True, and thats why it's important to have both the political time centre with a TZ database city, as well as coordinates as an options. They are both different things. TZ database city covers the political time based on a political centre, and is future proof for that use case. Coordinates cover changing political centres. If a country border moves but you need to specify a time that will update with any boundary ch…

The problem with coordinates is that they don't necessarily cover changing political centres. The opinion of the true legal time will differ based on political calculations. In a territory that is internationally recognised as Ukraine, annexed by Russia but under the contested control of Ukraine, how does the coordinates help? They probably don't. You'll have to know whether that particular time was from the Ukrainia…

Even city names may change depending on who or when you ask, so this does not seem like a maintainable solution.

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

#62

Post by shpx »

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 value in this timestamp with a Unix timestamp.

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

#63

Post by butlerm »

rapsey wrote: post #6
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.

Scheduling tasks on a system is done using UTC/local time which the system keeps accurate. Unix time is not used for that.

I am not aware of any operating system kernel that schedules tasks or timer expiration using a strict definition of UTC. Unix time is the most common, and local monotonic (non-decreasing) clocks are becoming common for that as well.

Of course there are application level schedulers that use wall clock time in UTC format, and if you set the clock back your task may run twice, which is a more serious real world problem than running twice around a leap second. That is why no one who is not attached to civil time should use UTC or Unix time for short duration timer expiration in particular.

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

#64

Post by gpderetta »

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…

> let’s do it correctly this time and start counting from 0001-01-01

[...]

> one subgroup of one profession naming a whole time epoch was kind of pretentious.

I think that the UNIX epoch is bless contentious that the other epoch, as is not tied to a religious event. OS wars not withstanding.

Also the UNIX time was specifically designed for UNIX.

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

#65

Post by hoseja »

Not to mention all these are measured inside the gravity well of Earth and Sun, introducing relativistic dilation (of, apparently, about 600 picoseconds per second [this value would have resulted in the first relativistic leap second in Unix Time this October]).

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

#66

Post by ilyt »

Anyone find it weird that they just abolished it without picking up replacement first ? Feels very "let have future us worry about that problem".

It does feel very unscientific but ultimately the UTC won't get out of sync from rotation for more than a minute in my lifetime (unless desync rate increases I guess) so I don't really care

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

#67

Post by ilyt »

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

That reminds me of WH40k, a fantasy universe where time/date was tracked based on when the last contact/sync [1] with earth's time has occured, with similar idea as NTP stratum.

I guess for multiple planets some astronomical recurring event could be used as sync source (say have "tick" be determined by some pulsar and adjusted for doppler shift)

* [1] https://warhammer40k.fandom.com/wiki/Imperial_Dating_System

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

#68

Post by beeforpork »

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. We need to see that no changes are needed to existing code.

We need to reduce complexity, e.g., by removing an irregular, unpredictable drift between TAI and UTC.

We do not need to rewrite legacy code to use a shiny new API, but we need to make sure that legacy code will not break, because we do not know, unfortunately, were all that code hides.

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

#69

Post by ilyt »

PurpleRamen wrote: post #56
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,…

Generally a good Idea, but writing the location-names or even coordinates in the timestring seems like bloat and slightly unreliable as it does not documentate from which point in time and which culture the timestring originates. As it's necessary to use a database anyway, why not just put a timezone-id there? 2022-11-23T08:52:02!tz:423 Just have the rule to never change an entry in the database, only allow appending…

Having multiple time zone databases to sync and manage sounds like even worse idea.

ID, well, it saves a tiny bit of space but honestly I don't think it is worth it if you're already storing info about timezone as text.

If you're storing it in binary form you can convert the name to DB entry on save/display

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

#70

Post by PurpleRamen »

ilyt wrote: post #69
PurpleRamen wrote: post #56

Earlier quoted context omitted.

Generally a good Idea, but writing the location-names or even coordinates in the timestring seems like bloat and slightly unreliable as it does not documentate from which point in time and which culture the timestring originates. As it's necessary to use a database anyway, why not just put a timezone-id there? 2022-11-23T08:52:02!tz:423 Just have the rule to never change an entry in the database, only allow appending…

Having multiple time zone databases to sync and manage sounds like even worse idea. ID, well, it saves a tiny bit of space but honestly I don't think it is worth it if you're already storing info about timezone as text. If you're storing it in binary form you can convert the name to DB entry on save/display

My point is, Timezone-Names alone are not completely reliable. They only name the location, but not the political or historical situation of this location.

Take Europe/Berlin for example, the city was once divided in two parts, and is now in a country which is changing timezone twice a year. With a location, you can only communicate to use the rules valid today, not rules which were valid at some point in the past, or which are valid today, but in a different situation/context.

Post reply on HN