You'd save a bit in some cases but now you'd have the problem of trying to schedule meetings because "8 am" is no longer tied to an area, so you have to now take location into account, which is what timezones already do.
8am is already not tied to an area. If you say "let's meet at 8am" in an email to a bunch of people and don't know where they are there is a good chance that most or maybe even all of them will show up at the wrong time.
I always just basically ignore TZs and always use UTC when communicating with my international team. Only using a single timezone for everything simplifies things a lot.
How do you handle DST? That's the only wrinkle I can see, recurring meetings changing time based on the season. With location-specific meetings, we've been lucky so far and all countries involved switched to DST at around the same time.
That's exactly the issue -- you want your local meeting at a particular local time, and if you schedule it in UTC, the meeting shifts by an hour twice a year.
this isn't a solvable problem with a sufficiently dispersed group. not even all US states observe DST, let alone all the countries in the world. you can't set a recurring meeting that will always be at the same local time for everyone.
Which is fine when you know the other people are in another zone, except they then have to do the conversion in their heads. If you speak like most people do when not thinking about time zones you just say a time. If time is the same for everybody then there is never any confusion. The computers are all doing it in UTC under the covers. The conversion is just because we have arbitrary layers on top of that.
PDT meaning? The reason for using Continent/City is that it's unambiguous and it's easy to find out what the time is in a city -worst case you can ask someone who lives there.
But PDT is unambiguous. It is used for nothing except Pacific Daylight Time. That was standardized a long time before the Olsen database which added Continent/City as a convenience.
Luckily, I'm in the middle of a work-avoidance session, and I found some delicious trivia[0].
'''
Unlike most of the United States, Arizona does not observe daylight saving time (DST), with the exception of the Navajo Nation, which does observe DST. The Hopi Reservation, which is not part of the Navajo Nation but is geographically surrounded by it, also does not observe DST. For this reason, driving the length of Arizona State Route 264 east from Tuba City while DST is in place involves six time zone changes in less than 100 miles (160 km).
'''
That’s a problem I already have, because I can never remember what time zone people or places are in. On the other hand, with a single time zone, there is never any ambiguity about what time someone/something is referring to (Eastern or Western? DST or non-DST? Etc)
You still have to remember where people live. Just because it's 9am everywhere doesn't mean people on he opposite side of the globe will work through the night.
That's already a solved case: communicate using UTC times when dealing with people in other timezones. It then becomes their responsibility to know their time relative to UTC. There are even sites that you can set a clock for a specific UTC time and when people visit the URL it will use their local time so they don't even need to deal with converting to/from UTC at all - technology does it for them.
