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