[samwillis]

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, science, precise measurement, simulation and such using TAI is clearly the cleaner, most robust solution. But as soon as you have a humans "perception" of time as part of the system a timezone aware timestamp is required. But even then, the most common version of that ISO 8601 is flawed.

ISO 8601 only has a fixed offset, it has no concept of timezones or geolocation. Borders between timezones move, DST windows change or disappear, it has no way to account for that. What we need is an extended ISO 8601 that includes a location rather than offset. Human time is tied to a geographic location in time. I think we need something like this:

  2022-11-23T08:52:02!Europe/London

using the names from the TZ database: https://en.wikipedia.org/wiki/List_of_tz_database_time_zones

or even coordinates:

  2022-11-23T08:52:02!51.509865/-0.118092

we probably even want planetary body:

  1969-07-20T20:17:00!Moon/0.67416/23.47314

This is the only way to store "human time" in a future proof way.

Physical moment in time = TAI timestamp

Human perception of a moment in time = Geolocated timestamp

[Someone]

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 been the subject of a dispute between India and Pakistan since 1947, and between India and China since 1962”

⇒ I expect there are events that are recorded to have happened at three different times, depending on who you ask.

https://en.wikipedia.org/wiki/List_of_territorial_disputes has many other territorial disputes, including ones between Canada and the USA (https://en.wikipedia.org/wiki/List_of_areas_disputed_by_Cana...), but most of them won’t be across time zones.

Also, there are other calendars in use than the Gregorian one. Most confusingly, some groups still use the Julian Calender.

[samwillis]

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 changes this is the only way. The coordinates also don't have to match the location of the event, they are specifying the "human time" reference point.

[nirimda]

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.)

[GauntletWizard]

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.

[lodovic]

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

[LinusU]

> 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

[twic]

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!

[mkraft]

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 include locations: ISO 8601 purposely excludes those because converting a location to a UTC offset is a political process that requires lookups for historical changes to that conversion.

[samwillis]

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 other planetary bodies, or other locations in the universe the first part of the time stamp could use any other format that could be in use at that location. It doesn't have to be tied to an Earth centric system.

> ISO 8601 purposely excludes those because converting a location to a UTC offset is a political process that requires lookups for historical changes to that conversion

My point is we need a standardised interchange format what actually takes that into account as that is how humans actually operate.

[pmontra]

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.

[ilyt]

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

[karmakaze]

Different than the UTC/TAI issue: A limitation of only using UTC timestamps came up when I worked at a social photo sharing company. We needed to define how to store and transport them, and everyone was saying UTC is the answer and I was arguing for local time + TZ and/or location.

The example I used was if New Years pictures were posted by a photographer in say New Zealand that was being viewed by someone in the US. Showing the US local time for that photo doesn't indicate how many minutes before or after midnight the photo was actually taken. For data transfer, ended up using strings for local date/time and location to ensure that nothing tried to interpret and transform unless explicitly intended.

[atoav]

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

[supportlocal4h]

Speed relative to what?

[atoav]

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

[PurpleRamen]

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.

[ilyt]

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

[PurpleRamen]

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.

[bombcar]

And parts of Mexico used to be the same timezone as Los Angeles but then daylight savings time changed and the city you referenced has to change.

There’s no way to look at America/Los Angeles and know if that is California or Oregon, and if Oregon were to give up daylight savings time you’d have a problem.

[iudqnolq]

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.

[fragmede]

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.

[nly]

It's fairly unusual to have a system where people can write timestamps in arbitrary timezones. Most of the time there's a suitable context where a timezone just makes sense

For example, in a booking system the timezone will be associated with the venue or the destination.

In a scheduler for a trading system certain timestamps (start, stop time etc) will be the timezone of the trading venue.

For past events (logging) UTC essentially always makes sense.

[faebi]

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