Please please please read (all of) my sibling comment to the one you're replying to. You're absolutely right about points in time but you're drawing tbe wrong conclusion from it and seem to be unaware that "13:00 on the 12th Sept 2025 according to whatever time conventions are in place in London at that time even if daylight savings is abolished in the UK between now and then" is perfectly expressible using a timezone (Europe/London).

▲

umanwizard 3 days ago | parent | next [-]

Europe/London is one of the names of a time zone, yes (variously also called Europe/Lisbon, WET, etc.). But what about for cities that don’t have a canonical name in tzdb? You can’t just always do Continent/City; America/Tucson, for example, does not exist.

▲

kelnos 3 days ago | parent [-]

That's not how those named zones work. I live in San Francisco, but my TZ is America/Los_Angeles. You don't need a named zone for every city; you can just pick a large city in the region where time is and always has been the same.

If SF decided to drop DST, but the rest of the state didn't[0], then America/San_Francisco would be created to handle the changes.

This is why you can't accurately record physical appointments by date, time, and timezone. You have to record it as date, time, and physical location, and then the time zone can "float", based on the location and rules in the tzdb, until the appointment happens.

[0] Assuming this were made legal, which is pretty unlikely.

	▲	umanwizard 2 days ago \| parent [-]
		I think you’re agreeing with me. My point was that the tzdb named zones do not provide a generally accepted way to denote “the time in Tucson” or “the time in San Francisco” that would be robust to those splitting from Phoenix or LA, respectively. You need to use some system other than tzdb named zones for that purpose (e.g. lat/long, like you mentioned).

▲

fauigerzigerk 3 days ago | parent | prev [-]

What is my incorrect conclusion?

What I'm saying is that we cannot reliably store a future local time such as "13:00 on the 12th Sept 2025 Europe/London" as an instant in time.

▲

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

"13:00 on the 12th Sept 2025 Europe/London" is already (a pointer to) an instant in time as much as any unix timestamp. Just a different reference frame. Now it's true you can not know in advance what UTC time will be at that moment which may bring practical concerns if one wants to synchronize that with a contemporary typical computer system clock. It would be true to say that not all points in time can be reliably stored as unix timestamps[0].

Recalling Einstein and that such a thing as global time reference is fundamentally impossible, you're nitpicking while being technically incorrect.

[0]: but please keep defaulting to it in code unless you really know why lol

https://doi.org/10.5281/zenodo.17070518

▲

fauigerzigerk 3 days ago | parent [-]

All I am saying is that it would be incorrect to _store_ a future date/time such as "13:00 on the 12th Sept 2025 Europe/London" as an instant in time, because the instant it refers to is yet to be determined. This is a very simple and pragmatic argument that matters when you choose data types for your database schema.

▲

3np 3 days ago | parent [-]

And I am saying that storing it verbatim as the string "13:00 on the 12th Sept 2025 Europe/London" is an instant in time as much as any other formats and types you can come up with. Just not very parsable by your typical stdlib.

It all boils down to picking the appropriate reference frame, which varies by context. I believe your point should be that there is no single universally applicable reference frame for mapping all future events to future cultural time (and/or that in any case it's not UTC).

▲

fauigerzigerk 3 days ago | parent [-]

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

▲

omnicognate 3 days ago | parent | prev [-]

No but we can and should store it as a timestamp with a timezone. It is rare for a nominal (date)time to be the correct thing to use. Please do read my other comment.

▲

fauigerzigerk 3 days ago | parent [-]

>No but we can and should store it as a timestamp with a timezone.

It would be highly unusual and misleading to call something a timestamp unless it is a point in time. In Postgres for instance, the timestamp with timezone type represents an instant in time.

This data type cannot be used to store things like reminders for future appointments. It's not rare at all.

▲

akio 3 days ago | parent [-]

That is not quite right. In Postgres, timestamptz (aka timestamp with time zone) represents an instant in time. timestamp (aka timestamp without time zone) represents what you are calling local time. timestamp (without time zone) is exactly what you should use to store future appointments.

Something that often trips people up is that they think timestamptz stores a timestamp plus a time zone (probably because of its unfortunate name). It does not; it always stores a Unix epoch without an extra time zone, converting any zoned timestamp that it is passed.

	▲	fauigerzigerk 3 days ago \| parent [-]
		Yes, you are right.