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 44 minutes ago | parent [-]

But that is _exactly_ the problem.

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.

	▲	jprjr_ 7 minutes ago \| parent [-]
		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"