Unix time is bad and needs replacement, not UTC • Hacker News Board

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

#91

Post by twic » Wed, Nov 23, 2022, 7:18 PM UTC

LinusU wrote: post #58

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

> I think we need something like this: > 2022-11-23T08:52:02!Europe/London There is a IETF standard proposal, which is very closed to getting finalised, that defines a similar format: 2022-11-23T08:52:02+01:00[Europe/London] ref: https://datatracker.ietf.org/doc/draft-ietf-sedate-datetime-... It's already in use by the Temporal TC39 proposal, which defines new types for working with temporal data in JavaScript. ref:…

It's still a bit of a weird format, because it has an offset and a zone. What does your example mean, given that it has an offset of +1 hour, on a date when in the zone you've specified, the offset is +0?

For more fun, what does 2024-11-23T08:52:02+00:00[Europe/London] mean now, and what does it mean if the UK switches to a +1 hour offset all year round in 2023?

If i understand the proposal correctly, the actual moment in time represented by one of these is given by the time and the offset. The bit in square brackets is just metadata. The spec says:

> This document does not address extensions to the format where the semantic result is no longer a fixed timestamp that is referenced to a (past or future) UTC time.

But that result is precisely why we need this!

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

#92

Post by GauntletWizard » Wed, Nov 23, 2022, 7:48 PM UTC

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…

The engineering solution to this problem isn't to add more parity bits to deal with the political changes, it's to use TAI, and make sure that TAI is well run and consistent.

We will need to encode planetary time origins, and should think about the equivalent, but I don't think that the solution to that will happen until after we need it to happen.

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

#93

Post by WorldMaker » Wed, Nov 23, 2022, 8:01 PM UTC

zowie_vd wrote: post #82

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

> That being said, it's unclear how people would solve the problems that will arise once that long time has passed.

I feel like we should be able to easily "bundle" leap seconds into existing leap days on leap years. Make February 29th just some random number of seconds shorter or longer than, say, February 28th. Most people feel February 29ths are weird anyway, few people would probably notice when they have strange amounts of seconds in their final hour. Some software might hate it if Feb 29 23:59:56 rolls over to Mar 1 00:00:00 or much more rarely there's a Feb 29 23:59:62 (or using the existing Unix time "smearing" technique, some Feb 29 you get three or more Feb 29 23:59:59 timestamps in a row), but other than that it would 1) be on a predictable day, and 2) a day that's already a weird every 4 years except every 400 outlier that's already expected to be an edge case.

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

#94

Post by iudqnolq » Thu, Nov 24, 2022, 12:47 AM UTC

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

It's even more complicated than that. Whether timestamps should change when timezones change depends on the use case.

"Let's meet at 8am Mar 3 2023" probably shouldn't become "Let's meet at 7am Mar 3 2023" if the timezones shifts.

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

#95

Post by fragmede » Thu, Nov 24, 2022, 1:37 AM UTC

iudqnolq wrote: post #94

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

It's even more complicated than that. Whether timestamps should change when timezones change depends on the use case. "Let's meet at 8am Mar 3 2023" probably shouldn't become "Let's meet at 7am Mar 3 2023" if the timezones shifts.

Wellll, that depends. The base case, sure. but meetings are between two or more people. so what do you do when one of the people is in a different timezone from the other, with different dates for daylight savings time crossover? a solution can be reached, but it's not clear that the meeting time shouldn't move.

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

#96

Post by atoav » Thu, Nov 24, 2022, 6:39 AM UTC

supportlocal4h wrote: post #76

atoav wrote: post #36

Earlier quoted context omitted.

Given the findings of general relativity we might also wanna include the speed of the object in fractions of lightspeed ; )

Speed relative to what?

That is the obvious catch of keeping time in a universe where everything and their dog moves.