[InclinedPlane]

This is a hugely bad idea. You'd still need a system to keep track of local relative time of day. For example, let's say you need to schedule a phone call with someone in another part of the world, how do you determine what time you should call? There are many, many other similar problems. How do you encode all of that information? It turns out, you'll need something almost as complex as the time zones we have today. There's no escaping the irreducible complexity of the problem, there are just ways of shifting it around.

[tsotha]

It's still simpler than time zones. If you schedule a meeting for time x, everyone knows when x is without having to do any translations.

[anonymouz]

But when scheduling the meeting for time x you'll have to look at the time offsets of all the participants to figure out if x falls into their work day or into the middle of the night.

If you schedule a meeting at 13:00 UTC, is the Chinese guy still in his office? Is the one from the US already in his office? Instead of knowing their timezones and their offset you'll now have to know their office hours in UTC, which means things keep being just as complicated as they were before.

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

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

[finnw]

Office hours are not consistent in local time either - there are cultural variations. If you want to know what (UTC) times the Chinese guy will be in his office, you need to ask him, not try to predict using offsets from UTC.

[ghshephard]

In the approximately 10 countries that I work with - they are all available from 9:00 AMsh to 5:00 PMsh. This may be unique to my sector (Energy/Utilities) - but it's pretty much consistent Across Brazil /UK/ Portugal /Germany /Japan/ Singapore /Australia /Malaysia /US /Luxembourg)

I don't work (yet) with anyone in China, so I can't comment on that country.

[InclinedPlane]

Look, UTC time already exists. How about you start an experiment. Whenever you schedule meetings or do anything that involves a time, use UTC. Maybe add in a little note about it in a signature or something, in case someone gets confused.

Report back in a year on your results.

[zanny]

The problem is that something like time standards requires collective initiatives to move towards them, because in all honestly 95% of people don't even know what UTC is. It is in the same class as an American (like myself) who does measurements in the metric system and pisses everyone else off because I don't use a system of measurements based off the length of a kings foot.