Railroad "Time Zones" of the United States (1868) (opens in new tab)

London to Sydney is a poor example because it takes a very stupid person to fail to realize their _brother_ who is on the other side of the world isn't up at midday.

But how about New York City and San Francisco. People do that _today_, because it's 8AM in New York and they forget it's 5AM in San Francisco -- or reversed, and it's 8PM and 11PM.

Why is that a problem? Because people have to keep track of the timezones and then do the math (most people are shockingly bad at basic arithmetic). That's a problem _today_ that you are ignoring.

> Abolishing timezones doesn’t make coordination problems easier. In fact, it makes them harder.

You claim that but you haven't demonstrated that. And the evidence I've seen points to the opposite.

Three brothers, Tom, Dick and Harry all live in the same city, in the same timezone. They know that Tom gets up early and goes to bed early, Dick gets up late and goes to bed late, and Harry travels so God knows when he's awake. They _know_ this and don't call Tom late at night, Dick early in the morning, or Harry without knowing where in the world he is.

Now spread those brothers around the world and the same thing is true: Tom gets up at 1000Z and is asleep by 0200Z, Dick gets up at 1700Z and is asleep around 0900Z, and God knows about Harry.

No timezones, a single clock and much simpler arithmetic. This also makes planning meetings easier.

Timezones are a 19th century solution to a 19th century problem. They _FAIL_ at our 21st century world.

In retrospect this makes sense but in the late 19th century, no one could have foreseen this use case.

One might be a clock face with local solar time as light/dark patches portraying the "movement" of the sun. Perhaps digital UTC in the center. A button to switch cities, etc.

I've seen a few implementations of this with LCD clock faces. They don't typically show UTC as well, but could. Once implemened getting everyone to use it would be the hard part.

Yet it comes crashing down when you think that for people in Barcelona 3PM is mid afternoon. Or that nothing's running at 6AM in Tokyo. Or whatever you assume is happening at 6PM in the Shichuan area.

Those are all random assumptions that could be better served by a sunrise - zenith - sunset representation (which has not much to do with time of the day anymore), or heck, checking the typical day rythm of that place, instead of hypothesing in our heads. Not counting that what someone does in a day will be highly variable depending on their occupation and personality.

Knowing that it's currently 7PM in India also helps me in no way to decide wether it's a good time to phone a store. Checking the store website will help a lot more.

Same way if I'm traveling I want to align my wake hours with the stuff I actually plan to do. If that means waking ay 9PM for whatever reason, then 9PM it is.

We can do better than keeping heuristics that only match very small patterns, that basically shatter when we're talking about the other side of the world.

Eh, maybe. I'm not convinced.

Does everyone in your office work the same hours?

We _already_ have the problem of "What are Bob's work hours" because most office workers don't work the same hours. Some folks come in early, some work late -- some come in late and leave early.

That has been common for decades and has become even more pronounced with increased remote work, particularly across time zones.

We shouldn't build our society around a myth of 9-5 office workers.

Nah they don't. Skipping over the (common on the internet) parochiality of assuming that US military practice is just 'what the military does'...

The US military certainly uses UTC/Zulu time for time stamping messages and coordinating operations globally, and timekeeping during extended missions (like submarine patrols, or air missions), but military bases and even surface vessels underway keep somewhat local time. They don't use Zulu time - that would mean the date changes in the middle of the day. You wouldn't be able to use words like 'next Tuesday' without having to disambiguate. It'd be crazy.

Zulu - Z - is just the last of the alphabetically named military timezones: https://en.m.wikipedia.org/wiki/Military_time_zone, which is a NATO standard.

If it's a timezone that has its operational properties change, you have the potential for confusion where there is disagrement about when a given time happened or will happen; think about how fun it is when daylight savings rules change. Sometimes, although not really that often, a time zone's offset is simply changed; hopefully with warning, but maybe not.

If the timezone has daylight savings, you get to deal with all the fun of most days having 24 hours, but some having more or less.

If the organization moves to a new time zone, either because it physically moves or because the locality its in changes time zones for whatever reason, now you have a problem; it's not fun to deal with multiple time zones in server infrastructure, but now you have to pick if you want to move all the servers, move only some servers, or have your servers in a different time zone than your org. If the last option was fine, you might as well use a sensible timezone to begin with.

2. Daylight savings mean that events an hour apart can end up having the same timestamp.

See: Google

That didn't stop them from independently listing Dayton, Cincinnati, and Columbus Ohio, all with different times (even though Dayton and Cincinnati are only 1 minute apart).

Back in 1868, there were essentially just two rail networks in the US - the eastern half and the western half. They met in Chicago. The operational model was very different, and the presence of Great Lakes shipping (with low summertime shipping rates) kept either side from trying to expand to be truly nationwide.

In essence, a timetable relative to Washington D.C. showed Sacramento just as an example. No railroad went from D.C. to anywhere west of Chicago. Not only did you change trains, you changed railroad companies.