[zanny]

You still have to ask for times they are available. That never changes. With UTC as the global time standard, you don't have to try to figure out time offsets. You just say "I'm available from 8 to 12" and they say "I'm available 5 to 9" and you make the call at 8. The alternative is "I'm available 3 - 7 London time", the other guy is available 12 - 4 Pacific Time, and you have to get out a calculator to figure out what those times actually are in relation to one another.

[lazerwalker]

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.

[InclinedPlane]

It's not just meetings, it's everything. Let's say you run a chain of stores that you all want to be open the same relative times. How do you list the hours on your website? With time zones this is easy, you just say "all stores open 8am to 9pm M-F", or what-have-you. Without time zones you have to specify the UTC time for each store or for each region. E.g. Stores in California open from 16 to 05 UTC, stores in Texas open... And now you see another problem, because now a time during the day locally is running over into night. So how do you specify the hours you are open relative to the days of the week? Are we using local days of the week or UTC days? So now if you are closed on the weekends locally that translates to the last day being open on Friday/Saturday (UTC).

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.

[mnutt]

If we all operated in UTC time, you would probably very quickly get a feel for when other people are at work. I'm on the east coast, and when working with people on the west coast I often just imagine them as working 12pm-9pm.

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.

[tsotha]

>I'm on the east coast, and when working with people on the west coast I often just imagine them as working 12pm-9pm.

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.

[mike_herrera]

If we're just wanting to know what phase of the day it is, at a particular location, a sun projection is a good enough approximation.

e.g. http://www.die.net/earth/

[dllthomas]

So, the one case gets way easier; the other gets no harder. Seems like an improvement to me.

[ghshephard]

Most of us who have to deal in multiple time zones have a Web Page/Dashboard/App of clocks with all the time zones that we deal with. 45' away from me I actually have a physical wall of clocks with cities noted above them.

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.

[tsotha]

>Most of us who have to deal in multiple time zones have a Web Page/Dashboard/App of clocks with all the time zones that we deal with. 45' away from me I actually have a physical wall of clocks with cities noted above them.

... which you could dispense with if everyone went on the same time base.

[ghshephard]

Here is my current Algorithm for setting up a meeting (which I do a lot):

    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.

I repeat that algorithm (as do our partners) 2-3 times a week, and have done so for the last 2+ years that I've been in emerging markets. It works really well. I know, for instance, that I have a bit of wiggle room with Utilities on the _early_ side (I.E. I can get them to start at 8:00 AM usually), but less so on the late side (most of them don't stay much after 5:00 PM).

If we Switch to UTC, what's the easy way of determining when their equivalent of 9:00 AM and 5:00 PM is?

[tsotha]

You don't care what the equivalent of 9:00 AM and 5:00 PM are where they live, because that's not actually what you're interested in knowing. You want to know when you can schedule meetings with them.

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.

[ghshephard]

"The easy way would be to just keep a list of the other party's available hours in UTC."

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.

[dialtone]

This is fairly easily solved by coloring the background area of those clocks a different color when they are supposed to be in-office. All the clocks will be on the same time and the backgrounds will be rotated depending on the culture of the area. With a very quick glance and without comparing N clocks, you can immediately see if all clocks have the time in the colored background and then set the appointment/make call.