One local time zone problem I hadn't anticipated, in an early startup...
I made our launch networked factory stations use UTC, to aid debugging with the various servers involved. (Such simplifications help, especially in debugging and incident response, especially when you don't yet have centralized observability.)
But the first time I had to investigate a problem remotely, on a station at a factory in Asia, the timestamps from various systems weren't lining up. I quickly realized that the station clocks had somehow gotten set to local time there.
Turns out that, when some of our team flew out to install the stations in the high-end factory in Asia, factory personnel noticed that there was a UTC time on screen for a few seconds during station startup, before it finished booting into the fullscreen appliance UI.
Factory personnel were so alarmed by a factory machine with the "wrong" time, that my people on the ground made the decision to change it to local time. (I suspect it was alarming because some other factory machines had operation procedures for personnel to ensure that the time is correct.) And in all the excitement of a successful launch, they forgot to tell me.
Maybe an additional reason against a single time zone: aoption resistance from people who don't understand, or who just like the local time.
For example, I can imagine many people stubbornly using "shadow" time zones for various purposes, and only using the official time zone when required (and this being error-prone).
There was a small communication failure incident: not telling me about a judgment call, in all the excitement, and when we didn't have comms as it was happening. (I have a few other stories about comms there, for another time) We addressed that oops constructively, as soon as it was realized. But that's not the problem I meant to highlight.
The problem I meant to highlight was that there can be surprising local resistance to something like UTC time, from people who aren't IT nerds. In this case, resistance to something we didn't even think they'd see during boot. And that prompts thinking about other ways there might be resistance, and what might happen due to resistance.
The factory manager and staff have their own way of doing things, and part of working well with them is figuring out what that is. Especially when you'll be thousands of miles away if problems come up. It turns out some things were intuitive, and some things weren't.
The people on the ground made a judgment call that this wasn't the thing to communicate harder or spend political capital on, and I support them making that call.
I made our launch networked factory stations use UTC, to aid debugging with the various servers involved. (Such simplifications help, especially in debugging and incident response, especially when you don't yet have centralized observability.)
But the first time I had to investigate a problem remotely, on a station at a factory in Asia, the timestamps from various systems weren't lining up. I quickly realized that the station clocks had somehow gotten set to local time there.
Turns out that, when some of our team flew out to install the stations in the high-end factory in Asia, factory personnel noticed that there was a UTC time on screen for a few seconds during station startup, before it finished booting into the fullscreen appliance UI.
Factory personnel were so alarmed by a factory machine with the "wrong" time, that my people on the ground made the decision to change it to local time. (I suspect it was alarming because some other factory machines had operation procedures for personnel to ensure that the time is correct.) And in all the excitement of a successful launch, they forgot to tell me.
Maybe an additional reason against a single time zone: aoption resistance from people who don't understand, or who just like the local time.
For example, I can imagine many people stubbornly using "shadow" time zones for various purposes, and only using the official time zone when required (and this being error-prone).