Live data from Hacker News

Unix time is bad and needs replacement, not UTC

z.vandillen.dev

51–60 of 96 posts

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

#51
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.

Around the time TAI drifts an hour from UT1, the current definition of UTC will require several leap seconds each year to keep in sync. So there isn’t much point saying that we have to keep the current definition of UTC to avoid leap hours, because the current definition of UTC will not work that long. https://www.ucolick.org/%7Esla/leapsecs/dutc.html

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

#52

Earlier quoted context omitted.

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.

I didn't necessarily mean 5 different timekeeping devices (though that would probably be more convenient in many cases), rather than an astronomer needs to keep track of multiple different "times" concurrently.

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

#53
post #44

Earlier quoted context omitted.

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

It makes sense that moon dates are in sync with Earth, after all its motion is in sync with Earth too. Mars days are slightly longer than Earth's ones but there are more of them in a Martian year. You want months and years to be local if there are seasons that affect life on that planet. I expect that Mars will have its own months and years but they'll know Earth date for quite a long time, at least until they'll have to depend on Earth for survival.

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

#54

Earlier quoted context omitted.

Astronomers don’t care, they already need like 5 different clocks. Also the allowable variance between UTC and ut1 is 0.9.

Exactly - and if astronomers don't care, what other reasons are there to require accurate synchronization of UTC (and civil time) with earth's rotation?

Considering the rate of progress, timestamps might need to be replaced with reference-invariant coordinates.

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

#55
post #35

Earlier quoted context omitted.

I expect you’ll find that a single spot on earth can have multiple values of the current time, depending on who you ask. For example, India, Pakistan, and China are each are in their own time zone, and ( https://en.wikipedia.org/wiki/Jammu_and_Kashmir_(union_terri... ) “Jammu and Kashmir is a region administered by India as a union territory and consists of the southern portion of the larger Kashmir region, which has…

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 Ukrainian perspective or the Russian perspective. In most cases that will be easier to code by a tzid than geographical coordinates.

Another example is Xinjiang province, where in some towns everything is in local time, in some towns everything is in legal time, in some towns it depends on if you're Han or indigenous, and in some towns it depends on what you're doing (bus timetable vs shop opening hours).

Another example is in a very large but lightly populated part of Australia, where there local community uses a defacto timezone (Australia/Eucla) but the legal timezone is different (Australia/Perth) - it is no use saying that the polls close at 6pm and the general store closes at 6pm and coding them with the same coordinates, because one will refer to a moment 45mins after the other. Other places may have similar variations of opinions where the formal boundary of two timezones isn't really obvious - I have heard that the timezone boundary around Broken Hill is a matter of opinion as much as it is a matter of law.

The other possibility is of course that perhaps in a country like the US where timezone boundaries are relatively unstable over time because they pass through states. It's true that coordinates could be used to deal with it. But it's not obvious that this is such a systematic and regular form of variation that timestamps should use coordinates, especially considering almost any record that relates to time in a place probably already codes the place so an ad hoc migration should generally be possible. (In such a case, I would still like tagging the time with a tzid so you know for a fact whether it is premigration or a postmigration.)

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

#56

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 new entries. This way, you can be sure that different timezones for the same location/coordinates are always matching the correct timezone. Any recalculation can be maintained in the database with rules, if necessary. And you are even independent of language and political changes for a location.

And you can even maintain multiple versions of the database, if neccessary. Just change !tz to !tz2, !tz3, etc.

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

#57
As much as I appreciate the topic, I fear this will be one of those 14 to 15 standards transitions. The proposal is complex in that it proposes three time units.

I see a lower-bound case for two: sun/Earth time and universal time. Farmers must be able to express "I will plant seeds at noon on August 29, 2329". They care about how the sun affects Earth. The worker trying to schedule a meeting is the same, because they'll want to guarantee the meeting happens during daylight. As such, I find the obsession over "always use Unix timestamps" a bit weird. Yeah, they're simple, but semantically wonky for some practical things. Everyone else, dealing with durations and time deltas unrelated to geological conditions want TAI.

For the farmer, the problem is the Gregorian calendar is deeply flawed/inaccurate, not that UTC has/had a leap second. Sun and Earth rotations are not aligned, so we cannot expect these to line up. We need year, day of year and time of day. The year is just the "number of solar turns" integer. The first and last day of the year would have to be cut up in unsavoury ways to account for misalignment. The time of day only needs to line up with Earth's rotation, but this means the speed relative TAI will need to shift as Earth is affected/slowed by the universe. (Now, I would suggest making the clock zenith based on something around the poles or leaning of the Earth axis, to end the Greenwich bias: that's pretty damn arbitrary.)

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

#58

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: https://github.com/tc39/proposal-temporal

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

#59
I hope that, when they redefine UTC, they define a new name for it. UTC has been the same timescale since it started; the history of redefinitions of GMT is a horror-story.

I guess what I'm really saying is that UTC-without-LS won't be UTC; rather, we'd declare that the new universal civil-time timescale is to be UTC-without-LS. You could carry on computing old-fashioned UTC after the transition; but one wouldn't generally use UTC to render civil-time for display.

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

#60

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

Yes. Even storing a datetime from the future requires you to choose the correct DST the date is in, instead of the current one.
Post reply on HN