3 ms·
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
by 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 agoPorblem 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 ;-)