Some industries do this using UTC. For example flight departure and arrival times are in UTC on all paperwork. And also the meteo reports and forecasts, and airspace restrictions, and airport opening times etc.

Mostly out of a necessity that fights tend to cross timezones and planes come and go from all over the world and they don't want to have to figure out everywhere what the local time is.

Really only passenger info screens convert to local time.

The biggest downside would be the date rolling over during a record-keeping period. But this is already a problem and people handle it just fine. I mean, we say "tonight" for 02:30 on the following day, so meh.

No no no. We can't make the world adjust to our crappy code.

24:00 is "mid night". 02:30 is not less 'tonight' than 21:30, assuming no DST.

> But this is already a problem and people handle it just fine. I mean, we say "tonight" for 02:30 on the following day, so meh.

Because that only affects the comparatively small number of people awake respectively events happening at that time of day. If you move the calendar date change right into the middle of the waking hours of almost everybody else, things get quite a bit more annoying.

I'm willing to make that sacrifice if we can delete python's time zone library.

Swatch tried unsuccessfully to sell people on this idea back in the late 90s:

https://en.wikipedia.org/wiki/Swatch_Internet_Time