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.
Unix time is bad and needs replacement, not UTC
51–60 of 96 posts
Re: Unix time is bad and needs replacement, not UTC
#52Earlier 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.
Re: Unix time is bad and needs replacement, not UTC
#53Earlier 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…
Re: Unix time is bad and needs replacement, not UTC
#54Earlier 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?
Re: Unix time is bad and needs replacement, not UTC
#55Earlier 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…
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
#56This 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,…
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
#57I 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
#58This 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,…
> 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.
Re: Unix time is bad and needs replacement, not UTC
#59I 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
#60This 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,…