Hacker News new | past | comments | ask | show | jobs | submit login

If anyone wants to convert from a given time zone to your local time zone, you can use: date -d '2014-03-14 14:25 PDT'

Google does this conversion automatically on their own outage pages.




3 letter timezones are ambiguous though. For example, Australia's east coast timezone is "EST"/"EDT" just like in the US. If you want to present time in a non-UTC timezone, you really need to use syntax like "UTC-0700".


From the 'date' command manual, there's more readable alternatives:

show New York time 14:25 in your local time zone: ~$ date --date 'TZ="America/New_York" 2014-03-14 14:25'

show New York time 14:25 in Alberta time zone: ~$ TZ="Australia/Alberta" date --date 'TZ="America/New_York" 2014-03-14 14:25'

On a GNU/Linux system, for more timezone strings see ls -Ral /usr/share/zoneinfo/


It's bad customer service to require a user to crack open a terminal in order to understand your announcements. UTC is coordinated universal time. It's a standard. Just use it.


Better still would be to use some kind of JavaScript that converts the time into the local browser's time zone. Or a link to such a service.


Just don't put that script on your event schedule pages. I've seen more than one conference make that mistake.


Sadly, the user's TZ isn't available to JavaScript. This is why so many sites have you input that as part of your preferences.

You can get the local time with JS, and you can get UTC, and from those two you can narrow it down (you know the current UTC offset, but that's it), but you're not going to get a single answer.


But you're just converting one time to another. If you know their reported UTC time and their reported offset to local, isn't that all you need? For greater precision, ask for their geolocation or use an IP address to narrow down the possibilities, though offset obvious helps.

Now that I think about it, you could auto-suggest based on offset and embed a list of locations per option if they needed to pick between daylight savings or not, for instance. There's room for an interesting widget or service, but it would need to be updated almost as much as a US sales tax calculation widget ;-)


Why hasn't this been fixed yet?


It seems like it has been, but it's basic. http://norbertlindenberg.com/2012/12/ecmascript-internationa... A more complete version might look like goog.i18n's timezone support in closure, though I'm sure you can link the two.


> For example, Australia's east coast timezone is "EST"/"EDT" just like in the US

I've always seen it refered to as AEST/AEDT, reducing the ambiguity.


There are other ambiguities - try Ireland, Israel, and India for IST [1] Turns out those abbreviations aren't part of an official standard anyway, afaict, so best to avoid altogether.

[1] http://en.wikipedia.org/wiki/List_of_time_zone_abbreviations


For converting without using Unix tools

http://www.timeanddate.com/worldclock/converter.html




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: