points by williamdclt 21 hours ago | 0 comments
If application engineers did their job correctly, they have nothing to update because you should store future events as a wall clock time + timezone, not an instant (ie something like `2026-09-01T09:00:00, America/Havana`, not `2026-09-01T09:00:00-05.00`).
Which means that flight booking systems are _probably_ fine (they're probably the domain that cares most about timezones and time changes so they've probably modelled it right), but many systems are not fine because it's such a common thing to get wrong.
[–] pwagland 21 hours ago
[–] jprjr_ 20 hours ago
I'd imagine the choice is driven by a whole lot of factors like which is the busier airport. It's probably easier to adjust the Cuba departure than the Miami arrival.
It's kind of like how some parts of the country should really be in a different time zone but they keep in sync with a nearby, bigger city. I'd imagine the smaller airports/airlines just say "yeah your Cuba flight is leaving an hour later so we stay in sync with Miami"
[–] williamdclt 17 hours ago
Ah, good point, I spoke too quickly (will I ever not fuck up anything that involves timezones...)
I'd guess that the Cuba side changes, so that all changes are localised to one airport, which is probably much easier than changes at every destination airport
Flights take x hours in the sky, and so would have left at `2026-10-01T09:00:00, America/Havana`, and arrives at Miami at `2026-10-01T10:25:00, America/Havana`.
Now, they have to choose, do they arrive at 10:25, and leave at 10:00? Or do they leave at 9:00, and arrive at 9:25, since only _one_ of those two timezones is changing. It is extraordinarily unlikely that they'll choose to just circle in the air for an hour so that they can just keep the same departure and arrival times.