[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.