9 ms·
To GitHub and everyone: please use UTC timestamps when there are potential readers outside of your timezone. Since every technical person should know their curr
by eik3_de 13y ago
To GitHub and everyone: please use UTC timestamps when there are potential readers outside of your timezone. Since every technical person should know their current UTC difference, calculating the local time is easy.
- noja 13y agoIf 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.
- agwa 13y ago3 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".
- slug 13y agoFrom 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/
- vacri 13y agoIt'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.
- lstamour 13y agoBetter 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.
- couchand 13y agoJust don't put that script on your event schedule pages. I've seen more than one conference make that mistake.
- deathanatos 13y agoSadly, 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.
- herokusaki 13y agoWhy hasn't this been fixed yet?
- lstamour 13y agoIt seems like it has been, but it's basic. http://norbertlindenberg.com/2012/12/ecmascript-internationalization-api/#Identifiers 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.
- herokusaki 13y agoWhy hadn't that been fixed yet?
- lstamour 13y agoBut 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 ;-)
- madeofpalk 13y ago> 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.
- oneeyedpigeon 13y agoThere 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 http://en.wikipedia.org/wiki/List_of_time_zone_abbreviations
- raverbashing 13y agoFor converting without using Unix tools http://www.timeanddate.com/worldclock/converter.html http://www.timeanddate.com/worldclock/converter.html
- imbriaco 13y agoYou're totally right. I just adjusted the post to convert the times to UTC.
- eik3_de 13y agoThank you!
- smackfu 13y ago>Since every technical person should know their current UTC difference, Awww, that's so optimistic.
- elwell 13y agoDon't forget the ancient proverb handed down to us from the original neckbeards: "At some point in their career, every programmer must pass through the fires of timezone hell."
- munificent 13y agoEvery programmer must enter those fires, but it's not certain that all of them will survive to emerge from the other side.
- derefr 13y agoTimezone hell is, of course, followed up with the three-headed hound of locales, charmaps, and keyboard layouts. And if you pass by that, you drop into the river of cache coherency... (Esoteric software-engineering topics could make a wonderful video game, you know?)
- ramses0 13y agoTurkey Test: http://www.moserware.com/2008/02/does-your-code-pass-turkey-test.html http://www.moserware.com/2008/02/does-your-code-pass-turkey-...
- ericd 13y agoI once wrote a scheduling SAAS app, thinking it would be a short, trivial project. It turns out that UTC offsets don't even stay consistent within time zones throughout the year due to differences in daylight savings policy. It took a bit longer than I expected.
- ams6110 13y agoWe've probably all been there at one time or another, thinking that "unix timestamps" are all that's needed to represent and perform date/time calculations. Along with the recommendation to never inventing your own cryptography, you should also never write your own date/time routines. Use well tested functions in your database or programming language libraries.
- jap 13y agoI'd rather see the local time for whoever is writing the article. I'm not a machine, and hopefully neither are they.
- azatris 13y agoThat is when you live in the US of course. Europeans, to my knowledge, all use GMT and have nearly nothing to do with UTC.