The problem that people are trying to solve by abolishing time zones is the annoying need to deal with time differences when scheduling meetings. The "I need to consult a table to schedule meetings" problem.
But we've just moved the problem under another shell. Now, in order to schedule meetings, I have to know what the universal "04:00" means for all participants. This is just the flip side of the same coin.
The real fundamental problem is that people like to work "during the day" and sleep "during the night". Either we solve that problem with time zones tables, or we solve it with "what is the solar time of day" tables. The author of this article is arguing, and I agree, that trading one for the other doesn't improve the situation ("is not simpler"), has a lot of human transition costs, and that the new problem may not ACTUALLY be an improvement over the old problem.
The problem that people are trying to solve by abolishing time zones is the annoying need to deal with time differences when scheduling meetings.
No, abolishing time zones and DST would also remove huge swathes of code in all of today's operating systems, numerous costly bugs, and make time unambiguous without qualifiers like time zone or location. There are lots of reasons to do it.
As others have pointed out, the real fundamental problem is best solved by people indicating their status somehow now and in the future, because not everyone in a country works 9-5, not everyone is available all of that time for phone calls, and why should everyone work to the same schedule anyway?
If you want to schedule calls, use a calendar, if you want to make a call right now, use an availability indicator.
"No, abolishing time zones and DST would also remove huge swathes of code in all of today's operating systems, numerous costly bugs, and make time unambiguous without qualifiers like time zone or location."
Because we can be certain that, going forward, we will never need to talk about a time before we made the change.
> But we've just moved the problem under another shell. Now, in order to schedule meetings, I have to know what the universal "04:00" means for all participants. This is just the flip side of the same coin.
The failure cases are much better though. Say you screw this up, and you schedule the meeting at what you think is "09:00 Bangalore" but it's actually "07:00 Bangalore".
With timezones: You tell the guy in Bangalore to dial in at 09:00, he says fine, then he misses the meeting.
Without timezones: You tell the guy in Bangalore to dial in at 04:00, he either sucks it up or says "umm I'm still having my breakfast then" and you reschedule.
