Uncle Steve is the same number of hours ahead that he has always been, and that's a thing that could be looked up just as easily as finding his time zone. I think the author is greatly exaggerating the degree to which time zones solve any of the problems mentioned. Uncle Steve might be on a different sleep schedule from me, regardless of whether or not he's in a different time zone.
Days of the week definitely become interesting in a global UTC system, but noon used to literally mean "the sun is at it's highest point". I suspect that people would grumble for a year or two and then forget that another system ever existed.
I feel like days are a non-issue; they would just start at different times (UTC) in different territories. This wouldn't make things any more complicated than they already are (currently, if I want to talk to someone in Australia, I have to look up what time it is in Australia and infer the day of the week from that, if necessary. If everything is under UTC, I know what "time" it is, but I still have to look up what day it is).
Most of the issues time zones cause are not "day of the week" related anyways (at least in my experience), so I think having to figure out what day of the week it is somewhere else wouldn't be a common problem anyways.
There's certainly a bit of dramatization/exaggeration here, but the main point is that it doesn't really fix the stated problem while also being a huge change for everyone to adapt to.
If everywhere runs on UTC, they will still have different times when people are working/not working/sleeping so you still have to look something up and figure it out.
With time zones, you look up "What time is it?", realize it's 4:30AM and since most people around the world follow similar schedule, you quickly realize he's fast asleep.
Before UTC4ALL: is UB awake? what time zone is UB in? idk, what zone is Melbourne? +11? uh... carry the one... 6:25, maybe a bit early, let's try in an hour[1].
After: is UB awake? he said gets up at 13:30, so call in a couple hours.
You want to call someone, but you don't know when they're available? Maybe you should ask them, so they can tell you it's 13:30 to 4:00, with zero "is that my time or your time" worries. Or check your shared location-aware calendar, which already handles both cases equally well.
How often do you do several-thousand-mile phone calls without knowing anything about the recipient's schedule? Where I come from that's gonna be rude, send an async message instead.
1: yes, the math/calculated time is wrong. on purpose. as an example.
> Uncle Steve is zero hours ahead.
Uncle Steve is the same number of hours ahead that he has always been, and that's a thing that could be looked up just as easily as finding his time zone. I think the author is greatly exaggerating the degree to which time zones solve any of the problems mentioned. Uncle Steve might be on a different sleep schedule from me, regardless of whether or not he's in a different time zone.
Days of the week definitely become interesting in a global UTC system, but noon used to literally mean "the sun is at it's highest point". I suspect that people would grumble for a year or two and then forget that another system ever existed.
I feel like days are a non-issue; they would just start at different times (UTC) in different territories. This wouldn't make things any more complicated than they already are (currently, if I want to talk to someone in Australia, I have to look up what time it is in Australia and infer the day of the week from that, if necessary. If everything is under UTC, I know what "time" it is, but I still have to look up what day it is).
Most of the issues time zones cause are not "day of the week" related anyways (at least in my experience), so I think having to figure out what day of the week it is somewhere else wouldn't be a common problem anyways.
There's certainly a bit of dramatization/exaggeration here, but the main point is that it doesn't really fix the stated problem while also being a huge change for everyone to adapt to.
I think you missed entire point of operation.
If everywhere runs on UTC, they will still have different times when people are working/not working/sleeping so you still have to look something up and figure it out.
With time zones, you look up "What time is it?", realize it's 4:30AM and since most people around the world follow similar schedule, you quickly realize he's fast asleep.
tbh I think a more realistic depiction would be:
Before UTC4ALL: is UB awake? what time zone is UB in? idk, what zone is Melbourne? +11? uh... carry the one... 6:25, maybe a bit early, let's try in an hour[1].
After: is UB awake? he said gets up at 13:30, so call in a couple hours.
You want to call someone, but you don't know when they're available? Maybe you should ask them, so they can tell you it's 13:30 to 4:00, with zero "is that my time or your time" worries. Or check your shared location-aware calendar, which already handles both cases equally well.
How often do you do several-thousand-mile phone calls without knowing anything about the recipient's schedule? Where I come from that's gonna be rude, send an async message instead.
1: yes, the math/calculated time is wrong. on purpose. as an example.
thank you for sharing, I was trying to find something similar that explains why UTC everywhere is such a bad idea!