Hacker News Reader

Comment by jwilk | Hacker News Reader

Timezone abbreviations (like PDT) are neither human- nor machine-readable. Avoid them.

They'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).

How 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.

> 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?

+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.

Consider the time 24 hours after summer time ends? Then you probably want to consider you need to switch time-zones in your display.

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

Accessible copy here: https://en.wikipedia.org/wiki/List_of_tz_database_time_zones

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 ...

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.

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.

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.

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

Right. Even the UTC+7 forms are confusing. Best to use location based zones for input at least

http://www.pixelbeat.org/docs/linux_timezones/

Reply on news.ycombinator.com