>And I am saying that storing it verbatim as the string "13:00 on the 12th Sept 2025 Europe/London" would be an instant in time as much as any other formats and types you can come up with.

No, a future datetime expressed in this string format does not represent a specific instant in time. If you had multiple datetime values from different timezones in this representation, you wouldn't be able to sort them so that earlier ones come before later ones. If they were instants in time, you would be able to do that.

▲

hebocon 2 days ago | parent | next [-]

I'm jumping in here to hopefully clarify:

"13:00 December 25 2025 Europe/London" is local time but its Unix timestamp is an estimate depending on how the tzdata database looks right now.

"13:00 December 25 2025 +0100" is also local time but it is immutable.

Using the latter can only be done reliably for present and past (but it conveniently avoids looking up the offset later). All future times must use the former to be stable otherwise you should probably be using UTC.

▲

3np 3 days ago | parent | prev [-]

> If you had multiple datetime values from different timezones in this representation, you wouldn't be able to sort them so that earlier ones come before later ones.

That's irrelevant.

Besides, you could, assuming you have a timezone db on the side.

> If they were instants in time, you would be able to do that.

How do you synchronize with and translate to timezones in Andromeda?

	▲	fauigerzigerk 3 days ago \| parent [-]
		>That's irrelevant It is proof that your format does not represent instants in time because instants in time can be sorted across timezones. >Besides, you could, assuming you have a timezone db on the side. No, because you don't have future versions of the timezone database.