Now, that was my amusement for a couple of years.
Then I learned that there is Broken Hill, which follows a time zone different from the surrounding area because of the train track history. And there is Lord Howe Islands, which uses a +0:30 minute DST shift instead of an hour.
And then I learned that history also experimented with 20 minute and 15 minute DST shifts, and that double DST (or Hochsommerzeit in Germany) was quite common, too.
You can probably go on and on and on as you dig deeper, and at some point, anyone's mind will blow, I guess.
Russia tried to do what China does (one TZ) but it is pretty hard -- people like to be awake when the sun is up.
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
Longreach is about the same longitude as Melbourne - but compare the daylight hours:
I was quite surprised by some of the stranger rules out there, especially the regions that chose to skip a day for whatever reason. Timezones are complex! Far, far more complex than simple offsets.
For the tl;dr crowd, pulled from that article (although I highly recommend you just read it):
Abolishing time zones brings many benefits, I hope. It also:
- causes the question "What time is it there?" to be useless/unanswerable
- necessitates significant changes to the way in which normal people talk about time
- convolutes timetables, where present
- means "days" are no longer the same as "days"
- complicates both secular and religious law
- is a staggering inconvenience for a minimum of five billion people
- makes it near-impossible to reason about time in other parts of the world
- does not mean everybody gets up at the same time, goes to work at the same time, or goes to bed at the same time
- is not simpler.
As long as humans live in more than one part of the world, solar time is always going to be subjective. Abolishing time zones only exacerbates this problem.
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.
(I'm not arguing in favor of switching, just pointing out that we already have the descriptions for times of day)
Pedants that were concerned about the fuzziness of such words could hound the speaker for UTC.
"I woke up a few hours before the roosters' crow to catch a flight."
It would be awkward to say that today, but potentially less so in some alternate-dimension universal time zone world where it could be a common idiom for "wee hours of the morning". Hours would still have meaning, people at least have the thought that "roosters crow at sunrise". So you got up a few hours before sunrise, whenever that time was.
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.
China already tried getting rid of time zones, and even though it's only 5 time zones wide it caused enough issues that far western provinces use their own unofficial local time: http://www.theatlantic.com/china/archive/2013/11/china-only-...
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.
Trains presented the first time that 1) humans could travel at a sustained rate above about 10 mph, and 2) presented roadways on which it wasn't possible to spot oncoming traffic and decide, at any point, to simply pull to the side to let it pass.
There was also the matter of coordinating service with local pick-up and drop-off, and whatnot.
So now you had a requirement for all points along a linear track to actually agree on the answer to the question "what time is it now?"
"Local noon" was no longer an adequate solution, or at least, it wasn't adequate with the means available at the time for computing offsets between your local noon, my local noon, and Train Time.
Railroad engineers (train drivers), track switching controls, and other elements also had to be, or could be, coordinated. Uncoordinated switching leads to packet collisions, or in this case, literal train wrecks. Which are messy, bad publicity, and discourage business.
Hourly offsets were reasonably close to solar time (generally no more than 30 minutes off), and abstracted enough complexity that offsets could be calculated (a given train was unlikely to cross two time zones in a day).
This happened in 1883.
It has to be better than 9am is breakfast, noon is lunch, and 6pm is dinner; in that it has to be short and memorable.
The time of an event that happened needs to just be UTC; period.
The time that something is planned might not be an event, but could be a relative reference.
What does that even mean?
The only reason to use UTC is so you can compare timing of geographically diverse events easily (plus things like daylight savings). Local time is still local tmie.
Clearly it worked and no one uses the old system anymore. <irony off>
For me timezones are OK. They are a cultural construct developed to accommodate the custom of counting the hours from sunrise (later midnight) and higher numbers meaning later in the day.
Not every sociocultural construct is bad just because it causes us code monkeys some trouble.
And believe me. Trouble it causes day in day out to me.
So how do you live? ;)
Minor: Los Angeles doesn't have a constant offset to UTC. But it changes rarely enough that it's easy to absorb the inconvenience.
Major: if he was using Los Angeles time internally, he'd have all the same problems when interacting with anyone else. Using UTC internally, he still has those for counterparties that don't use UTC, but they disappear for counterparties that also use UTC. Using UTC is a strict upgrade in terms of interacting across "real changes in time".
When I interact with people in a different time zone, I like to use their time, because I figure the odds of them messing up when using their own time are low. But if I didn't do that, I seriously doubt they would have more difficulty with my proposal "let's meet at 04:00 UTC" than with my proposal "let's meet at 12:00 pm my local time".
Even more amusingly, thanks to the old "noon is when the sun is at its zenith", there are historical time zones that aren't representable as whole minute offsets from UTC either.
Luckily we ditched all of those before we invented leap seconds.
So much crazyness in the world of Timezones.
Or Morroco Timezone which does the DST dance 4 times a year rather than just 2.
I just wanted to say that I hate time zones with a passion.
Here is the table of most but probably incomplete rules.
Even in the EU, the eastern edge of Finland is over an hour east of the center of CET, while western Spain is two hours west of it. That means that during the spring and autumn solstice, even though we have 12 hours of day and 12 hours of night, the sun over western Spain sets three hours after eastern Norway. For Norway it makes sense, most of its people live smack in CET, but for Spain it's a purely political gesture.
I was adding "Night mode" to Nova Launcher, allowing a dark theme to be applied after sunset. To accurately calculate sunrise/sunset the location permission is required, but that's the only thing Nova Launcher needs the permission for, and only Android 6.0+ has runtime (optional) permissions so I didn't want to force the permission on everybody and needed a fallback.
I knew that time zones aren't offsets but locations (ish) and for calculating sunrise/sunset they should be close enough. Nova pulls the device's time zone (something like America/Chicago ), maps it to a lat/long, and calculates the sunrise/sunset. It just depends on how accurate the timezone data is.
Public beta went fine, but stable release we start getting a small, but concerning, amount of emails from people saying that their icons won't load, or disappear, after the update. We're asking for information trying to find a pattern, but it's across different Android versions and devices. Finally we notice all the carriers are Canadian. Then it gets more specific, it's Winnipeg (turned out it was actually Manitoba, the province Winnipeg is in). First thing I test is setting my device timezone to America/Winnipeg, but everything works fine for me. We're getting some more device information from the reporters, and their timezone isn't America/Winnipeg. but America/Resolute. That must be close to Winnipeg right?
Notice how far north it is.
And the sunrise/sunset times, or lack thereof...
I actually anticipated this, and there was some code to just use hard coded times for cities too far north to have a sane sunrise/sunset. However either that code broke later, or it only worked with GPS coordinates, and I assumed all the timezones were safe.
I don't know why carriers in Winnipeg report the timezone as Resolute, but the fix came in two stages. 1) Properly handle locations that don't have sane sunrise/sunset times. and 2) Treat America/Resolute as America/Winnipeg
And anyone who thinks they are qualified to write time related code by virtue of having coexisted with clocks and time definitely should not be writing time related code.
 Time handling is different than FP and crypto, in that most of the complexity is human-created and policy driven rather than deep math, but for whatever reason people really don't understand that time handling is very complex - it seems to be widespread Dunning-Kruger. So they repeatedly make bad mistakes with very strange-seeming trigger conditions that can't be debugged on demand until someone realizes it is a time related bug.
It is important to understand the difference so you can build a time system that works for everyone, not just the majority.
America/Detroit is a valid IANA timezone. Eastern is not.
Etzos has pointed out that US/Eastern is on the list. Thanks for correction.
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.
> some small country cancelled summer time with only a few days notice
- In April, Egypt announced daylight time would start July 7. http://english.ahram.org.eg/NewsContent/1/0/204655/Egypt/0/D...
- On June 30, Egypt decided daylight time would start July 5. http://english.ahram.org.eg/NewsContent/1/64/232199/Egypt/Po...
- On July 4, Egypt decided not to have daylight time. http://english.ahram.org.eg/NewsContent/1/64/232478/Egypt/Po...
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.
To add another layer of complexity, the tz database is capable of representing time zones whose definitions are themselves changing over time. If your state government decides to switch from Eastern to Central time next year, you still want to be able to accurately answer questions like "what was the current local time in this location at UTC instant t?".