Imagine organizing military responses or shipping logistics when you can go under an hour then forward and then under an hour again just crossing 3 countries.
Eh, it works fine in Arizona. The US uses daylight savings, but Arizona doesn’t, except for some of the reservations in Arizona that do. You can go forward and back an hour twice just crossing Arizona
Ninja edit: As I say that, I remember why I even know that - I once spent an entire morning working out a bug in one of my daily jobs. Turned out because a team member in Arizona wrote the script and scheduled it, and a different team member not in Arizona wrote an orchestration to collect results, they ended up off-sync once daylight savings hit. Maybe it doesn’t work
The true problem here is using individual floating reference time instead of fixed or shared reference times.
Programming should always use Epoch or UTC+0 internally. All translation to local time would be just that, a translation.
The majority of similar scheduling bugs is due to not being explicit with what your reference time is. For automated background tasks that should always be absolute time. It’s only when you’re scheduling in reference to events that run at times that are fixed to their local timezones that you should be referring to that kind of floating reference, and then you should link all the references together so everything connected to the event pulls the same timezone reference, etc
Any particular reason why a sovereign country can’t just decide to do this on its own? Why does it have to be a pan-european thing?
Time chaos in EU.
Imagine organizing military responses or shipping logistics when you can go under an hour then forward and then under an hour again just crossing 3 countries.
Time bandits even!
Now that’s a reference 👌
Eh, it works fine in Arizona. The US uses daylight savings, but Arizona doesn’t, except for some of the reservations in Arizona that do. You can go forward and back an hour twice just crossing Arizona
Ninja edit: As I say that, I remember why I even know that - I once spent an entire morning working out a bug in one of my daily jobs. Turned out because a team member in Arizona wrote the script and scheduled it, and a different team member not in Arizona wrote an orchestration to collect results, they ended up off-sync once daylight savings hit. Maybe it doesn’t work
The true problem here is using individual floating reference time instead of fixed or shared reference times.
Programming should always use Epoch or UTC+0 internally. All translation to local time would be just that, a translation.
The majority of similar scheduling bugs is due to not being explicit with what your reference time is. For automated background tasks that should always be absolute time. It’s only when you’re scheduling in reference to events that run at times that are fixed to their local timezones that you should be referring to that kind of floating reference, and then you should link all the references together so everything connected to the event pulls the same timezone reference, etc