3 ms·

You should probably use the time zone identifier from the IANA list, which would be 'Europe/Paris' or similar. https://www.iana.org/time-zones https://www.iana

You should probably use the time zone identifier from the IANA list, which would be 'Europe/Paris' or similar. https://www.iana.org/time-zones https://www.iana.org/time-zones Accessible copy here: https://en.wikipedia.org/wiki/List_of_tz_database_time_zones https://en.wikipedia.org/wiki/List_of_tz_database_time_zones

hyperman1 8y ago
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 ;-)
twic 8y ago
I suspect most normal people in the area which uses the central European time zone recognise the abbreviations CET and CEST, but would be pretty nonplussed to see a time described as being '14:37 Europe/Paris'. Particularly if they were German, Italian, Spanish ...
- andrewaylett 8y ago
  That's an argument for different display formats, where UTC offsets aren't the worst thing in the world but actually you should just display whatever your users want, which will often just be a time with no TZ indication at all. For storage of future events, use a proper TZ entry, or suffer like Microsoft did when the US decided to change the date it started summer time and everyone's calendar entries were off by an hour for a couple of weeks.

hyperman1 8y ago

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 ;-)

twic 8y ago

I suspect most normal people in the area which uses the central European time zone recognise the abbreviations CET and CEST, but would be pretty nonplussed to see a time described as being '14:37 Europe/Paris'. Particularly if they were German, Italian, Spanish ...

andrewaylett 8y ago
That's an argument for different display formats, where UTC offsets aren't the worst thing in the world but actually you should just display whatever your users want, which will often just be a time with no TZ indication at all. For storage of future events, use a proper TZ entry, or suffer like Microsoft did when the US decided to change the date it started summer time and everyone's calendar entries were off by an hour for a couple of weeks.