Time Zones Aren’t Offsets – Offsets Aren’t Time Zones

Now it's down to 2. Most of Alaska has been placed in the Alaska zone (UTC-9...the former Yukon zone, renamed because Yukon itself (in Canada) moved to Pacific at some point) and the extreme western Aleutians are on Hawaii-Aleutian time (UTC-10).

This posed some hardship, since most of the state is at least one hour earlier than its "natural" time (in some cases, two or more) but has the advantage of reducing the time offset between Alaska and the Lower 48. A mitigating factor is that due to the high latitude the sun's position and clock time have only a loose relationship anyway for much of the year.

People can easily be awake when the sun is up by changing their schedule. I've never been to China, but I guess in Ürümqi (today's sunrise: 6:35, sunset: 21:54) and Beijing (4:53-19:46) they adapt their schedule to the daylight hours.

A nice tool to check daylight hours through the year: http://www.timeanddate.com/sun/china/beijing

Note that this has the side effect of automatically making it so the extra daylight during times of the year with more daylight come at the end of the working day, without the need for daylight savings time.

What does that even mean?

Now, remove that bit of metadata and we need to figure out how to encode/transmit it again. At the end of the day, we just recreate time zones, with the added downside of removing a common language we have while traveling - Visit SF from the UK and not only are you jetlagged, but you need to remember that every time of the day you're used to needs to be shifted by 8 hours. - and just... talking to people in other time zones.

Right now, if you post a story on HN about needing to get up for work at 4:30am, everybody will understand: this person gets up for work really early! Move to UTC and it means nothing.

Time zones are a great example of complexity intrinsic to the problem. You can't get rid of such complexity, just move it around (or alternatively make your solution less useful).

Getting rid of time zones does simplify time calculations for a computer. But it increases complexity elsewhere and makes computers less useful.

This isn't all that complicated. Pick some astronomically-based event, say when the sun is at the zenith on equinox, and tie local time to that. Then, given that you have coordinates for every significant place on earth, it is an easy computer calculation to calculate the delta of time to where your uncle was sleeping.

Similarly, the offset to UTC is trivially available.

This is a calculation that ham radio operators, among others, already use to know what UTC the sunset or sunrise is (these are interesting times due to ionosphere changes around those times) at some random distant place far away, say Vanuatu.

Luckily we ditched all of those before we invented leap seconds.

http://www.jqueryscript.net/time-clock/Easy-Timezone-Picker-...

http://n.exts.ch/resource/post-30342bc1aac8ab98c817edee2b126...

http://docs.telerik.com/devtools/aspnet-ajax/controls/schedu...

Edit: Just want to clarify that "Eastern" and others are indeed on that list and everywhere I've needed them have worked in place of the physical location equivalent. The physical locations, however, are the standard for the respective timezones--I am not commenting on the correctness of the GP post.

Speaking as if the Olson tz database is authoritative and official reminds me of when some small country cancelled summer time with only a few days notice and our OS vendors were not going to be putting out a patch in time. While explaining the process of downloading the Olson tz database and updating systems manually, a coworker asked who gave them (the country's government) permission to cancel DST. It took longer than it should have for me to come up with an explanation that sovereign countries don't need permission from the Internet or OS vendors to change their laws and regulations. The computers track the government actions, not the other way around.