Well, for a start, they can't say 'we quit for the week at 5 on a Friday' in your global timezone scheme - they have to say 'at 04:00 on a Friday'.
And it's not that it's a Saturday for them when they wake up in their local morning, later on global Friday - that's a day that starts out Friday and turns Saturday halfway through.
Meanwhile in India, Saturday starts first thing in the morning. Europeans get to generally be in bed when the day ticks over, so it stays Saturday all day for them. But Americans have to put up with the day changing in the evening - Saturday started at dinnertime last night, and it's still Saturday when they woke up.
So maybe you solve that by keeping local day names consistent - in the Eastern hemisphere you keep the name of the day that you wake up on, while in the Western hemisphere, convention is the day name you use is whichever day starts before you go to bed.
Congratulations, now you have an informal unspecified timezone that tells you region by region whether or not people there think it's Monday yet. Eventually, someone probably would formalize that, in some sort of localization file keeping track of the offsets when different places consider 'day turnover'. That file would look a lot like a timezone file.
And this is all before you start trying to associate dates with time periods. If you get rid of timezones and assume that the only 24-hour periods worthy of naming are ones that run from 00:00 - 23:59 UTC, you've condemned most of the world to not being able to use dates to unambiguously identify a given sunup-sundown period.
You'd have to use 'day ending October 19' or something to refer to the daylight period, in your location, that ends during the global 24 hour period called 'October 19'.
Sorry - it's just a real bugbear of mine whenever software devs try to wish away timezones that they ignore the importance of 'local midnight' in defining the boundaries between local calendar days. You have to propose a solution for that too if you're going to seriously suggest getting rid of local time.
> Well, for a start, they can't say 'we quit for the week at 5 on a Friday' in your global timezone scheme - they have to say 'at 04:00 on a Friday'.
Just for clarification, when I said "5 on a Friday", I wasn't making the error of thinking that New Zealanders could say that they leave work at 5 p.m. on Friday, I was (perhaps naively) hoping that along with getting rid of time zones, we would also be moving to 24 hour time, so "5 on Friday" means "5 A.M. UTC" in our current time spec.
> If you get rid of timezones and assume that the only 24-hour periods worthy of naming are ones that run from 00:00 - 23:59 UTC, you've condemned most of the world to not being able to use dates to unambiguously identify a given sunup-sundown period.
That's correct. To my mind this is the only downside of getting rid of timezones. As the OP of this subthread said, I'm quite happy to end up with the worst possible 24-hour-period to daylight mapping out of all of them in exchange for getting rid of timezones. I simply think the upsides to the proposal are so extreme as to completely outweigh this one downside, even for a person "stuck" with the worst outcome.
In response to your other points, my view is that we really should bite the bullet and always use UTC for everything (or whatever, it doesn't really matter; if making Beijing our universal time is the only way to get China on board, I say we do it). In other words, we do not compromise to keep local day names consistent. We always and only use "Sunday" to refer to 0-24 hrs UTC. My view is that people would adapt to this rather quickly, much as they would adapt to our switching to the metric system, despite the enormous number of complaints you hear about that. (My understanding is that those in the US military already do this as "Zulu" time, which makes communication much easier.)
My only point vis-à-vis cross-continent business hours is that this strict UTC adoption proposal does not make anything more difficult than it already is, and in some cases may make things easier. Right now, you have to think about what time and what day it is for someone on another continent. In my imagined future, you have to worry about whether the person is normally working right now. It's effectively the same problem, but communicating about the problem has suddenly become easier, because you share a language in which to discuss your available hours.
And it's not that it's a Saturday for them when they wake up in their local morning, later on global Friday - that's a day that starts out Friday and turns Saturday halfway through.
Meanwhile in India, Saturday starts first thing in the morning. Europeans get to generally be in bed when the day ticks over, so it stays Saturday all day for them. But Americans have to put up with the day changing in the evening - Saturday started at dinnertime last night, and it's still Saturday when they woke up.
So maybe you solve that by keeping local day names consistent - in the Eastern hemisphere you keep the name of the day that you wake up on, while in the Western hemisphere, convention is the day name you use is whichever day starts before you go to bed.
Congratulations, now you have an informal unspecified timezone that tells you region by region whether or not people there think it's Monday yet. Eventually, someone probably would formalize that, in some sort of localization file keeping track of the offsets when different places consider 'day turnover'. That file would look a lot like a timezone file.
And this is all before you start trying to associate dates with time periods. If you get rid of timezones and assume that the only 24-hour periods worthy of naming are ones that run from 00:00 - 23:59 UTC, you've condemned most of the world to not being able to use dates to unambiguously identify a given sunup-sundown period.
You'd have to use 'day ending October 19' or something to refer to the daylight period, in your location, that ends during the global 24 hour period called 'October 19'.
Sorry - it's just a real bugbear of mine whenever software devs try to wish away timezones that they ignore the importance of 'local midnight' in defining the boundaries between local calendar days. You have to propose a solution for that too if you're going to seriously suggest getting rid of local time.