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.
Trying to remember the hours people work in Japan may be a problem, but I don't think it's any worse than trying to remember timezone conversions and I don't think it's a large enough problem to warrant varying the way people measure time. It may have made sense at the time, but today it is vastly overkill. That said, I doubt it will change anytime soon due to inertia.
This is a good point. When you work with people in other time zones on a regular basis you tend to do the conversion to your time zone once and treat them like they were local people working odd hours.
I know that my partners/customers/colleagues in all countries are available for calls from roughly 9:00 AM to 5:00 PM without ever having to ask them.
That's basically what TimeZones do for you - they provide a common basis to keep everyone in sync around with world, without me having to check, on an office-by-office basis what UTC hours they are in. It's just agreed that 9:00 - 5:00 is a reasonable time to schedule a meeting, and TimeZones tell me when 9:00 - 5:00 is for any particular office.
... which you could dispense with if everyone went on the same time base.
o What City are they in, (Say, Melbourne)
o Hit F4 (Dashboard on my MBAir)
o It's 7:40 in Melbourne. 5 Hour Behind. Set
meetings starting no early than 9:00 AM + 5 Hours.
If we Switch to UTC, what's the easy way of determining when their equivalent of 9:00 AM and 5:00 PM is?
The easy way would be to just keep a list of the other party's available hours in UTC. If you had to deal with a lot of people in a lot of different places, you could keep a list by major city the same way you do with time zones. The fact that you need to apply an "algorithm" to something that's inherently static should tell you the situation as it stands is inefficient.
Alternatively, I can just use TimeZones which does it for me, In every country of the world that I've worked with. This even accommodates daylight savings, when people come into work earlier/later at certain times of the year. And my algorithm takes all of 5 seconds per meeting - I wouldn't call it inefficient.
UTC is great for a lot of things (I was one of the people who introduced it to our NOC, ensured that on all servers, /etc/localtime -> /usr/share/zoneinfo/Etc/GMT so our log files could be easily correlated.) - but for figuring out when people around the world are available to work with you - local Time Zones do a much better job.
Also - as noted elsewhere, when I'm traveling from country to country - Having a local timezone to tell me if I'm landing in the morning/afternoon/night is invaluable. Once again - only possible with Local Timezones if you want to represent the time with a single number.