Worth mentioning, there's an ongoing debate about removing leap seconds, as they seem to cause more trouble than benefit they bring (UT1 and UTC being in sync).
Personally I've dealt with some unit tests around simultaneous use of multiple timezones (we had to show the timestamps in the local timezone of the respective event). One day a good chunk of them stopped working for no apparent reason.
After a lot of head scratching, I figured out an update of tzdata was responsible for it, since it added new planned leap seconds. Our underlying library was properly taking the leap second into account, but the test conditions weren't.
At my work we have a system where dates are in a local timezone, where the timezone depends on the data ingress point, but times are in New York local time.
So many bugs occur when juggling 2 or 3 timezones simultaneously.
I won't name it, but I can guess where you work, as the place I once worked had the same problem and surely not many places have made the same mistake.
Worst is where the NY local time jumps back due to DST and you have two actual points in time represented by the same numerical NY local time. That manifests itself as an hour long gap in the data for the Australian stock exchanges!
It shouldn't be problematic as long as the exchange stops trading for at least 2 out of 24 hours, since no DST shifts can bridge the gap and cause ambiguity.
24 hour exchanges are hosed though
Where do you work now and what mistakes have they made? :P
> It shouldn't be problematic as long as the exchange stops trading for at least 2 out of 24 hours, since no DST shifts can bridge the gap and cause ambiguity.
Actually one hour would do, but it has to coincide with New York 1am - 2am, not its own DST shift. If I remember right, only one or two exchanges had that problem in practice even though there are lots of Asian exchanges. In fact it might've been the New Zealand stock exchange rather than the Australian one. But yes all 24 hour exchanges are in trouble. This was a good 10 - 15 years ago now, so it's possible they've added a suitable hack to "solve" the problem.
I work for a small consultancy now where much of the software design choices were made by me. So naturally there are no mistakes ;-)
Personally I've dealt with some unit tests around simultaneous use of multiple timezones (we had to show the timestamps in the local timezone of the respective event). One day a good chunk of them stopped working for no apparent reason.
After a lot of head scratching, I figured out an update of tzdata was responsible for it, since it added new planned leap seconds. Our underlying library was properly taking the leap second into account, but the test conditions weren't.