|
For prescheduled meetings, you're absolutely right. "I'm available 8-12, and you're available 5-9, so let's chat at 8" is a clear improvement. But what if it's not a scheduled meeting? If it's the middle of the day where I am, and I need to give you a quick call to verify something, I need to figure out if it's appropriate to call and if you're likely to be in the office. Currently, that means converting my time to your time, as easy as looking up the offsets and doing a simple sum. Context clues make it easy to figure things out: if it's 10:30am your time, there's a high chance that you'll be in the office. If it's 3:30am your time, you're probably asleep. Sure, there are still cultural fudge factors at play (do you come into the office late, do you take a siesta, etc), but a ballpark estimate isn't hard. Assuming it's not an emergency, I don't care if I get your answering machine if you're in a meeting; I do care if you're offended that I woke you up. If we're both operating in UTC time, this conversion now requires cultural knowledge of what your working hours are before I can even get a big-picture idea of whether it's appropriate to call. |
Now let's say you want to buy a ticket for an international flight. You're only going to be staying for a few days so you need to plan the time of day you leave and arrive carefully. For example, let's say you want to fly somewhere for the weekend, you want to leave in the evening on Friday and begin your return in the evening on Sunday. Now you need to translate between UTC and local time and days to figure out which flights you want to take. Or, say you are taking a very long trip, from the US to Australia perhaps, and you want to arrive in the evening so you can eat dinner then go directly to bed. That too requires complex figuring if you don't have time zones.
Or, let's say you are a service oriented company and need to provide a response-time in your SLA, measured in business days. Well, do you have to introduce the idea of "local business days" now? How do you list local holidays? "Offices closed from 08 UTC Dec 25 through 08 UTC Dec 26"?
Ultimately you end up needing to have some sort of additional resource which tells you things like the local time, the local day of the week, etc. And that merely duplicates all the work we've already done with time zones. If you want to simplify time zones, that's a worthy effort, but getting rid of them is not the answer.