4 ms·

There are subtle differences between them. I saw one where a French contractor set up a superdome using Europe/Paris, while the server was located in Europe/Br

There are subtle differences between them. I saw one where a French contractor set up a superdome using Europe/Paris, while the server was located in Europe/Brussels. Turns out there is a period of a few months in I think 1937 where there is a 1 hour difference between them. This messed up birth dates: People get born the day before, at 23:00. So our software encountered an unholy trinity of bugs,legacy and the oracle SOAP stack. Unless all servers have the same time zone, these people got the birth day mangled when passing data between servers. Which means that superdome infected the time zone for every server created after it.

andrewaylett 8y ago
Dates are hard :(. Doubly so when interacting with other systems that may or may not be set up correctly. I'd never knowingly set up a server to use anything but UTC, because the server's timezone shouldn't have any effect on application code and this way, even people in the UK will notice six months of the year. In this particular case, it sounds like the application was creating data with an implied timezone without any verification that the timezone the _user_ was thinking of matched the timezone of the data, and you may have been better off not associating the point with any timezone -- or indeed with any time, just a date.
- hyperman1 8y ago
  Porblem turns up with xsd dates. Applications added time zones in the +2:00 format. The oracle soap stack helpfully simplified everything to a datetime. Today this zone is the same for Brussels and Paris. So each server decided to convert it back to its native format, then causes trouble when it encounters the past. I tried for a while to run my local development JVM with an insane default time zone, Japanese character set, etc.. I hoped to shake bugs out of my programs. Unfortunately, almost none of the libraries I have to use survived, so i had to change it back. Sure did find a lot of bugs ;-)

andrewaylett 8y ago

Dates are hard :(. Doubly so when interacting with other systems that may or may not be set up correctly. I'd never knowingly set up a server to use anything but UTC, because the server's timezone shouldn't have any effect on application code and this way, even people in the UK will notice six months of the year. In this particular case, it sounds like the application was creating data with an implied timezone without any verification that the timezone the _user_ was thinking of matched the timezone of the data, and you may have been better off not associating the point with any timezone -- or indeed with any time, just a date.

hyperman1 8y ago
Porblem turns up with xsd dates. Applications added time zones in the +2:00 format. The oracle soap stack helpfully simplified everything to a datetime. Today this zone is the same for Brussels and Paris. So each server decided to convert it back to its native format, then causes trouble when it encounters the past. I tried for a while to run my local development JVM with an insane default time zone, Japanese character set, etc.. I hoped to shake bugs out of my programs. Unfortunately, almost none of the libraries I have to use survived, so i had to change it back. Sure did find a lot of bugs ;-)