Chesterton.org, on the other hand, had me going through not one but two select-all-the-boats captchas to even see the content.
But the damn robocallers have destroyed the primary use case of telephones. When I was a kid the phone was for “important” stuff, and “tying up the phone” with an unimportant conversation or 1200 baud modem was frowned upon.
Take the argument that it is currently easy to tell whether or not it's a good time to call someone on the other side of the world. Currently, supposedly, all you have to do is look up what time it is there. This is, frankly, bullshit.
I call someone with roughly a 12 hour difference from me every two weeks. If you haven't pre-cleared a time to call, then you do need to know whether it's daytime there. Even if you assume the best case scenario for the argument: where you need to call someone now if possible, and want to know whether that's okay, time zones are absurdly enough not better than the no-time-zone case. I fail to see how at all how asking Google "what time is it in Melbourne" is any better than "is the sun up in Melbourne". Moreover, both of them run the same risk: your uncle likes to sleep in on Saturdays, is busy, has an unusual schedule, etc.
So the correct question to ask Google would be "is it daytime in Melbourne?" Furthermore, if we abolished time zones, a fairly standard nomenclature for talking about "daytime" in a localized way would surely develop. Asking Google a question like "what time is it in Melbourne" would respond with e.g. "it's 2 hours after sunset". Why assume Google would respond with useless information?
But more importantly this puts aside the fact that very few people actually interact this way with people on the other side of the world, or even most of us with friends and family who live on the other side of town! If you're calling someone you don't see often for a nice long chat, you don't know what their schedule is like! Instead you pre-clear a time to call with them, through some asynchronous method like text or email.
In this case the no-time-zone situation really shines, and that's why the other half of the argument doesn't work. Your uncle writes you back: "yeah, call me at 4!" and you instantly know what that means.
When I talk to my friend on the other side of the world, it's hell currently. "Wait do you mean your time or mine?" Usually he means his, so I have to go to a website, figure out the hour difference between his time zone and mine, and figure out what that time is in my time zone. If that doesn't work for me, I have to suggest an alternative, and he has to wonder if that's in his time zone or not. It's a mess! The worst part is that if you're writing each other asynchronously it could take you days to figure out what a good time to talk would be!
You can't even count on getting days right, currently! The other day he messaged me: "can't wait to talk on Friday!" And I had to think, "Friday? I thought it was Thursday. Wait, he probably means my Thursday and his Friday. I guess it is Friday for him. Maybe I still need to check..." This is absurd! Without time zones, there would be universal agreement about what day it is.
It's actually much easier than that. Just call them, and if they're asleep their phone will be on silent.
But honestly, who do you know who lives on the other side of the world, and you're close enough with them that you would give them an unscheduled call, but you're not close enough with them to know what times are good for them to receive phone calls, and you're worried that they would be upset by a phone call at a bad time?
Sadly, it's not so simple.
Let's assume we just globally adopt UTC. Let's suppose GlobalFriday starts at midnight UTC, and runs through to the following midnight.
For a person in Hawaii, midnight UTC happens around the middle of the day - early afternoon. So, Hawaiians who woke up around 18:00 UTC on a GlobalThursday greeted GlobalFriday shortly after lunch. They go to bed on GlobalFriday evening, and wake up again on... GlobalFriday morning. GlobalSaturday will be rolling around shortly after lunch.
The interesting question then is, do Hawaiians go to work on GlobalFriday mornings?
Let's assume they decide to. For them, Friday-Saturdays are a workday in Hawaii, but Saturday-Sundays and Sunday-Mondays aren't (this is how Hawaii's work week runs today - they end their week on what they call Friday evening around 04:00UTC on a GlobalSaturday, and don't show up to work until 19:00UTC on GlobalMonday).
What about Australia, though? If they keep their current work week, they finish up around 05:00UTC on a GlobalFriday for the weekend - When they get up on a GlobalFriday morning at 19:00UTC (they today call that 'Saturday') they don't head to work at all.
So Friday-Saturday is a workday in Hawaii, but not in Australia. If you ask someone to schedule a meeting Saturday afternoon, will they think that's fine, or think you're crazy? Depends if they're Hawaiian or Australian.
You might think 'we can get Hawaii and Australia to agree on working the same days'
Obviously, they could, but that pesky international dateline winds up needing to be somewhere.
Fundamentally, the model we have now where New Zealanders are the first to get up on Monday morning and the first to pack up on Friday evening - with the rest of the world following the same weekday schedule on a time delay behind them - is a reasonable compromise not just around having clocks make sense locally, but also around us being able to share the same calendar globally.
This is correct, but it doesn't show that there isn't disagreement about what day it is. It shows there's a (potential) disagreement about whether today is a workday.
Moreover, you're just re-describing a problem we already have now. If your business, based in Hawaii, wants to plan a meeting for Friday, and someone from New Zealand is supposed to be on the call, you're going to be disappointed to learn that they don't plan on going to work on what for them is a Saturday.
So this is in no way a problem solved by time zones, to the extent that it's even a problem. At least if you're in agreement about what date it is, the people in New Zealand can get back to you with a straightforward description of the problem: "sorry, we quit for the week at 5 on Friday, you'll have to schedule it earlier or bump it to next week".
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.
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.
But you don't just want to throw away local time. Local time is important shared nomenclature for "point in a day". If you throw away local time and just say "I had a visitor at 0300 yesterday" you're leaving it up to the listener to both figure out where you live and do the math for whether you had an unexpected night visit or somebody interrupted your dinner.
If I know where you are, then I already know what you meant by "yesterday". If I don't, then local time has no upside in that regard.
This is the internet. I don't make assumptions as to where people are located unless it is relevant to the topic
Besides, as the parent said, we already have a world time. Use UTC.
Good thing time zones are there along side UTC+/- whatever to help you out with that
''' 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). '''
PDT might be, but others aren't (e.g., ACT, ADT, AMT, and AST are all ambiguous, and that's just in the As)
Daylight Saving Time (DST) is not used for UTC as it is a time standard for all time zones
TLDR; Swatch make a decimal based 'world time' and watches/programs to track it ('beat time'). Put a huge 'beat time' clock on their HQ. It was supposed to cure all the internet scheduling woes...and then it died.
The current system is a lot simpler. You have a rough idea when people sleep and work: it's the same time in their time zone as it is for you in yours. (Unless you are as shifted as e.g. me :) . But even then, the 'normal' people follow a normal schedule.) You just have to convert it to yours. Not that hard.
It seems the status quo for remote companies is to standardize on whatever timezone the top-most boss is in. Doesn't seem optimal.
We support multiple timezones. PST and PDT.
Not to mention that a lot of countries mandate that the civil time should follow the Sun.
First, go buy an Apple Watch...
https://www.macstories.net/linked/the-beauty-of-the-apple-wa...
(It is a pretty cool watch face, and I use it a lot in the Pacific Northwest winter with its early sunset.)
The different between the longest and shortest day's amount of daylight is a whole workday.