You are technically correct but I’m not convinced it is “super important”. The stakes of not messing up appointment times in the very rare edge case of a territory changing time zones seems pretty low. I’m willing to be convinced that I’m wrong, though.

▲

akio 3 days ago | parent [-]

It is not as rare as you might think.

The most recent time this happened was March of this year, with Chile's Aysén Region dropping DST and moving to the newly created America/Coyhaique.

https://data.iana.org/time-zones/tzdb/NEWS

I used to manage a large application for scheduling shifts at warehouses in many different locations, and storing future events as local timestamps and lazily converting them just before calculations into their location’s zoned time was the only way I could stay sane.

▲

umanwizard 3 days ago | parent | next [-]

I didn’t mean it’s globally rare, i.e. rare that it happens anywhere. I meant that it’s a rare thing for any given person to experience.

Even for people who live in Aysén, it will probably only happen once in their lives, and the only impact will be a few appointments getting messed up. Is having to fix a few calendar entries once in your life really “super important” to avoid?

	▲	akio 3 days ago \| parent [-]
		The consequences could look something like 50 shift workers showing up an hour late one day, or a user missing a critical meeting. Dealing with and debugging time zones is already such a confusing mess that I find that anything that makes your application more correct with regards to time zones is worth it. The important thing though is knowing, and then you can make an informed decision on how may shortcuts you want to take with time zones. If you’re writing software that’s only designed to be used in a small region or by just a few people, then sure, it’s probably not super important. If you’re writing software that’s used all over the map in places and time zones you can’t predict, well, it helps me sleep better at night.

▲

omnicognate 3 days ago | parent | prev [-]

Why didn't you store them as instants (offset from epoch) or UTC? Using local times, wouldn't your software produce different points in time for the same event when run with a different locale?

▲

akio 3 days ago | parent [-]

The events in question happen at a physical location at a local time, and so are stored as a local time plus longitude and latitude.

If they were stored as instants, and then if a location moved time zones or stopped using DST in the summer, the event’s stored time relative to the expected local time would incorrectly shift.

▲

omnicognate 3 days ago | parent [-]

That's logically fine, although it strikes me as likely overkill since your system has to be able to look up a convention by lat/long in order to get an instant in time, which is not trivial to do and for most use cases would be a more frequent source of errors than changing timezone definitions. I don't know the details of your use case though, and this could well be the appropriate representation. The main thing is that enough information is present to identify an instant in time. Your scheme isn't the nominal-datetime-only representation that I pointed out is frequently used but rarely correct.

	▲	akio 3 days ago \| parent [-]
		We agree that you generally want some information that lets you resolve your event to an IANA time zone for calculations :)