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.
Timezone 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?)
I 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.
We'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.
At my first job I inherited a project from a snr dev who decided to implement his own date logic instead of using the ones provided in .net
Anyway come feb 29th 2008 I get a call about some users were having issues. After not to long I figured out it was caused because of the leap year and his logic did not account for leap years. So I called them back and told them it would fix its self by tomorrow. I never actually bothered to fix the bug because a) I thought it was unlikely that the pos system would still be used in 4 years and b) the code was so bad in all areas that trying to fix anything had a good chance of breaking something else.
Lets just say that job was very character building
There was a comment in a piece of code I was looking through once which read, "Except here universal time is actually Pacific Time, maybe they will get the prime meridian moved."
Much of the code assumed that all times were in PST and the commenter had apparently been incorporating data sources from other time zones into the code. I thought it was pretty funny.
Except I have the unholy irrational evil daylight savings time in my area and I can't remember when the clocks go forward or backwards so I can't tell when my UTC offset is right or not.
UTC most certainly does not have DST. Many people use GMT as a synonym for UTC, and in that sense, it doesn't either. Britain goes to "BST" (British Summer Time) during the summer. From Wikipedia[1]:
> Greenwich Mean Time (GMT) originally referred to the mean solar time at the Royal Observatory in Greenwich, London, which later became adopted as a global time standard. It is for the most part the same as Coordinated Universal Time (UTC), and when this is viewed as a time zone, the name Greenwich Mean Time is especially used by bodies connected with the United Kingdom, such as the BBC World Service, the Royal Navy, the Met Office and others particularly in Arab countries, such as the Middle East Broadcasting Center and OSN. It is the term in common use in the United Kingdom and countries of the Commonwealth, including Australia, South Africa, India, Pakistan and Malaysia, and many other countries in the Eastern Hemisphere.
> Before the introduction of UTC on 1 January 1972, Greenwich Mean Time (also known as Zulu time) was the same as Universal Time (UT), a standard astronomical concept used in many technical fields.
> In the United Kingdom, GMT is the official time during winter; during summer British Summer Time (BST) is used. GMT is the same as Western European Time.
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".
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.
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 ;-)
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.
