top | item 45157206

(no title)

akio | 5 months ago

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.

discuss

order

umanwizard|5 months ago

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|5 months ago

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|5 months ago

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|5 months ago

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.