4 ms·
Timezone abbreviations (like PDT) are neither human- nor machine-readable. Avoid them.
by jwilk 8y ago
Timezone abbreviations (like PDT) are neither human- nor machine-readable. Avoid them.
- rocqua 8y agoHow to represent the CEST timezone then? Writing "Central European Summer Time" in full is very big, but UTC+2:00 is actually something else than CEST. I think standard abbreviations are a nice middle ground, at least when a time-zone is needed. Otherwise, just report stuff in UTC.
- chrismorgan 8y ago> UTC+2:00 is actually something else than CEST I presume you’re referring to the fact that CEST is +0200, but +0200 is not necessarily CEST?
- gpvos 8y ago+0200 suggests it's +0200 all year long. CEST means you've configured something like the Europe/Brussels time zone and the time mentioned falls in the summer period.
- rocqua 8y agoConsider the time 24 hours after summer time ends? Then you probably want to consider you need to switch time-zones in your display.
- andrewaylett 8y agoYou 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 agoThere 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 agoDates 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 ;-)
- twic 8y agoI 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 ...
- hyperpape 8y agoThey're useful where the human has enough context to know they'll be looking for one of a handful of timezones (e.g. someone in the US looking at an event in the US).
- pixelbeat__ 8y agoRight. Even the UTC+7 forms are confusing. Best to use location based zones for input at least http://www.pixelbeat.org/docs/linux_timezones/ http://www.pixelbeat.org/docs/linux_timezones/