Communication

The most prevalent issue with timezones is the impact on communication in a globalised society. As more and more companies spread their team worldwide, timezones will become more hindrance than a help. Currently, almost everyone can name numerous times where timezones have messed up a meeting or other event.

When talking about time with someone in a different timezone, you either need to calculate what time will be for them or tell them the time in your timezone and have them figure it out themselves. Not only does this add extra complexity and latency to what you're trying to communicate, but it also requires conveying and knowing more information. This additional step is akin to having to use translation software for critical phrases in mid-speech. Not only is this more complex to comprehend, but it also introduces the chance for mistakes.

Software Complexity

Timezones are very complicated, and due to this, they are challenging to support in software accurately. A large amount of engineering effort goes towards timezone awareness in applications. While most timezone-aware software internally represents time in UTC, it is still a considerable effort to maintain. On top of this, not all software is timezone aware. Tom Scott from Computerphile goes over this in more detail than I can in this post, so I'd recommend checking out his video below.

Timezones aren't good at being timezones

The fact that daylight saving time exists is arguably the most significant sign that timezones are arbitrary and meaningless. Not only does it show that people are okay with local time changing, but it also indicates that local time changing does not matter. Both timezones and daylight saving time are notorious for changing for purely political reasons. In Queensland, Australia, daylight saving time was not adopted alongside the rest of the east coast in a political move to win favour from farmers.

Also, numerous geographical areas operate on multiple timezones simultaneously. In Arizona, the Navajo Reservation and the Hopi Reservation disagree on whether to use daylight saving time. A similar disagreement exists between the Israeli and Palestinian people. While these groups all occupy the same space, they can operate in different timezones.

Timezones also start to become even more arbitrary the further from the equator you are. In northern Canada, a daylight cycle doesn't exist for a sizable portion of the year. In places like this, syncing up a timezone to whether it is night or day doesn't make sense because it may not change for months.

Overall, these factors all contribute to additional complexity in both software and communication.

Abolish Timezones

The solution to this problem is for everyone to use UTC. On UTC, when it's 07:00 in New York, it's 07:00 in Sydney. Now, of course, people don't want to sleep during the day. Local regions should still adapt their "working hours" to whatever makes the most sense for them. However, instead of working from 09:00 to 17:00, someone may work from 24:00 to 08:00.

This idea initially sounds confusing, and while it would take some getting used to, it would overall lower complexity. People would get accustomed to their local times, similar to how some people are currently used to 09:00 being the start of a workday, for example.

Another benefit here is that it allows much more fine-tuned control over local times. One city could decide that the workday starts at 09:00, while another a small distance away may decide that 09:15 suits their physical location better. And unlike the mess of timezones, doing this does not matter. 9 o'clock is still 9 o'clock. Your place on the planet does not change time but instead changes the time you do things, which is significantly more logical.

On top of this, migration for computer systems is also relatively straightforward. Timezone-aware applications can do this already, as they generally store time using a Unix timestamp concept. Rather than converting this timestamp to local time, it would instead just display as UTC. Applications that are not timezone aware also have a simple migration path—migrating all current times to UTC, rather than making that current application timezone aware. Instead of becoming timezone aware, it's able to instead switch to the only timezone.

If you're wondering how the software will adapt to people having work hours at odd times, you'd be happy to know that software already does. Not everyone works 9 to 5. Many people have jobs at different times, and many people are shift workers and don't have a consistent schedule. If the software did not support other work hours, it already did not support a large portion of the earth's population. If anything, this would force developers to make the software more accessible.

More and more of the world is adopting UTC as well. Many industries that cannot have timezone-related confusions, such as the aviation industry, operate on UTC. As time goes on, it wouldn't be a surprise to see multinational corporations adopt UTC across their offices, eventually leading to a global shift in the way we know the time.