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 ;-)
So many bugs occur when juggling 2 or 3 timezones simultaneously.