But now we have computers to do all the bookkeeping. So if we wanted, we could not only return to the previous approach, but take it further to infinite time zones. Your noon is whenever the sun is overhead for you. Our calendars always include locations for events, so the time difference is compensated for. Google Maps knows that if you're traveling east or west a significant distance to make it to an event, it needs to adjust the time. Etc, etc.
Uh oh. I'm starting to think this is a good idea...
...the need to synchronize global tasks means that either you have easily-offset local times, or you just use UTC everywhere and keep it in your head when local wake / sleep is and refuse synchronized tasks outside those times.
I should note that I'm not seriously proposing it. My point is more to get people thinking. Our current hodgepodge approach is extremely historically contingent. I personally believe that there's no good solution to this, just different bad ones.
With one hour time zones:
* If someone is 3 time zones ahead, they're 3 hours ahead
* There are 24 time zones and 360 degrees neatly divides by 24
* 2 hours between time zones means that within a time zone, the sun rises on one side at 8 am and on the other side at 10 am.
I was explaining why 1 hour as the standard makes sense instead of 30 minutes or 2 hours. The :45 time zones would still be an issue for 30 minute intervals and :30 and :45 are still an issue for 2 hour intervals
But there are half-hour aligned time-zones. Newfoundland is -3.5. It's currently 11:20 am here in Toronto and 12:50 pm in St. John's. Then there's the Chatham Islands of New Zealand with a quarter hour offset at UTC +12:45.
There are also regions where two bordering time zones change by more than 1 hour. At the Pakistani-Chinese border you gain or lose three hours.
This part wasn't a conscious decision, because the reference frame of time and orbital mechanics were discovered long after the practice of timekeeping. We may have a similar problem on a galactic scale some day.
* Friday UTC 2300 = local time 4pm PST - This is Friday
* Saturday UTC 0100 = local time 6pm PST - Is this Saturday?
* Saturday UTC 2300 = local time 4pm PST next day - This is still Saturday?
When would Saturday afternoon be? We'd have to change our vocabulary, and I don't see that worth it.Most servers run on UTC under the hood, and a lot of big organizations have experience already in terms of doing all timekeeping calculations in UTC. It may seem weird, but works pretty well in the long run -- and not having to deal with corner cases like DST or geographical ambiguities around time is extremely valuable.
Have you ever thought about what it's like to live near the edge of a timezone? In a city where half the city uses one time and half uses the other?
China is fine, because the day doesn't change during daylight.
Yeah, computers should use UTC. It's easy for them to convert to/from local time for the user. This is what computers are good at.