When you travel to a different timezones you just have to adjust your clock and, without asking, you know that shops open at 8~10am until 4~8pm with or without a midday stop for lunch (12~3). You have dinner at 18~22, and breakfast at 8~10. All the divergences depend on the country you are in but you can get good aproximations that work for 90% of them (breakfast 9, open shops 10, lunch 13, close 17, dinner 20).
But, if you go for an universal timezone, you've got to learn the different times for the different activities again and again and again. You change a one step correction (change time on your watch) to a constant struggle.
With universal timezone: You wake up when travelling, it's 17:30 and you don't remember the country unless you do the mental effort to wake up, it's time to get up or not? You start to calculate and... too late to decide, you are already woken and could not get back to sleep even if you wanted.
With different timezones: You wake up when travelling, it's 2:30 and you don't remember the country unless you do the mental effort to wake up, it's time to get up or not? No, time to sleep some more.
I was in charge of a big supply database server on an aircraft carrier, and every time we changed timezones I had to update the timezone on the server. Heading from East to West was no problem, but when we went from West to East I had to shut the server down for an hour when changing timezones, to prevent timestamps from overlapping.
Admittedly, this was partially due to bad programming, but it's just a small real-world example of problems caused by the existence of timezones.
Given that servers frequently changing timezones can be sorted out by a modicum of thought by programmers and is actually pretty rare in the grand scheme of things, I don't think it's too heavy a price to pay.
Or UNIX time. While not monotonically increasing (it has issues with UTC leap seconds), it's pretty good.
You basically have to reinvent timezones every time you make any kind of calculation involving people in another timezone.
Similarly, you are on holiday and someone tells you a museum is open till 04:30. Can you go to dinner first?
I guess that a main question is what kind of query is more frequent: "What time is it now in X", or "At what time is X where I am now?". I thought the former was way more frequent, but now, I do not know anymore.
Maybe the best thing to do is to drop absolute references altogether. IMO, "Shall we meet in 3 hours" is easier for handling across timezone discussions, and will work equally well for "in a different timezone than the one I am used to".
Of course, your SMS/ping/twitter/email client would have to automatically count down such timers for you.
For someone who travels a lot, a single time zone may well be more inconvenient, hard to say.
Times relative to now would work well but could be unwieldy. How do you do it if you're e-mailing or texting? If you want to meet next Monday afternoon, do you say "in 2 days and 5 hours"?
With that system, how do you refer to a particular date? YYYY-MM-DD doesn't make much sense anymore, since a month can span multiple years, and a day can span multiple months and/or years.
First was the "Calendar Round", they had two non-synchronous "yearly" calendar of 365 days (Haab') and 260 days (Tzolk'in), giving a date in both calendars provided an exact identification in a repeating cycle (era) of 18980 days (~52 solar years).
Second was the "long count", a monotonically increasing calendar from a root date (think CE/BCE, except including days). A "long count" date is composed of a number of counters mostly in base 20: K'in (day), Winal (20 K'in), Tun (18 Winal), K'atun (20 Tun), B'ak'atun (20 K'atun) (dates have been found with even higher orders, but they're rare, those are the most common). A B'ak'atun unit represents ~394 solar years. This provides an unambiguous and very long term calendar. It's essentially what the UNIX system does, except starting from days (interestingly, a standard 5-units long count fits in just 22 bits, 31 bits [to account for signing] allows for 5.8 million years before wrap-around)
Sure, but back then there wasn't even a globally recognised calendar. Nor did they have a near-instantaneous global communications network, or a global governing body such as the UN. These days, if the UN decided to take such a step, they could give 10 years advance notice, and on the decided day everyone would just flick the switch. We've already shown that w are capable of managing this sort of change when we went through the y2k "bug" without any major dramas, despite this requiring a large percentage of the world's information systems needing to be updated / tested. So I personally wouldn't anticipate any significant friction after the UN signed-off.
The Y2K bug is a very different case. That's a case in which the calendar system was perfectly able to deal with reality, but some people had buggy code implementing it. All it took was those people fixing their bugs, mostly completely independently, not some big coordinated effort.
As for y2k, you know what, I could have stuck a load of different examples in there. Changes to http for example. Or how about the switch from national currencies to the Euro in Europe. Each one is different, but they all demonstrate that important changes can be made to large interconnected systems, and that the change can be activated at the flick of a switch if the need for synchronisation exists. Also, I assume you're too young to know much about y2k if you can talk so blithely about people working independently in an uncoordinated manner. Y2k was huge - if you change one system to requiring 4 digit years, but just one of the systems it communicates with requires two digit years, your system stops working. Both need to switch to 4 year dates on that interface simultaneously. When the systems you're talking about are command and control circuits, financial transfer systems etc, this was a major issue.
You might be able to get Europeans to transition, you might even get the whole rest of the world to transition, but without the United States, it's not truly a universal system.
The UN doesn't have that authority, either politically or morally. http://en.wikipedia.org/wiki/Durban_Review_Conference
This is the part that makes the least sense to me - I could buy the rest until then, but after that it starts to read like some sort of elaborate joke.
If there are ANY benefits at all from switching, then that benefit can be enjoyed every year forever, dwarfing the one-time cost of switching no matter how big that cost is.
Give me $1000 and I'll give you (and your heirs, their heirs, etc) $0.01/year forever. Give me $10k and I'll sweeten the deal to $0.15/year. Give me $100k and go to $2/year.
What? You don't believe that any forever benefit justifies any one time cost?
It seems like you thought "redesigning the calendar of every single organization in the world" meant re-printing the shifted dates when it actually means doing all of the work that has to go into scheduling events.
You also missed: "From simple mortgages to complex financial derivatives, he said, calculations could be made much simpler if there were only one calendar to use, year after year."
And: "Hanke said drug prescriptions could be more accurate with a fixed calendar, sports teams could have a fixed playing schedule year after year, and schools and universities wouldn't have to waste time devising each new academic year."
The rest of the arguments are really just throwaways. Not waste time devising new academic calendars? You're going to be devising new schedules each year anyhow, as the courses offered change, professors change, new students change and enroll in different classes, sports league pairings change, and so on. And the existing system doesn't require re-doing the basic calendar every year; you can devise 14 calendars up front (one for each day of the week, times two to account for leap years), and then do the scheduling within one of those 14 basic calendars. The cost of that is going to be pretty minimal, going from 14 calendars to 2 calendars isn't that big of a win.
Drug prescriptions? People are imperfect; they don't necessarily take drugs precisely and regularly, such that you can avoid all variance in the rate of drugs being prescribed. With many drugs, if you miss one dose, you just take your regular dose the next day, and are now off by a day from the prescription cycle. Or sometimes, people might take a little more of a drug than prescribed, or lose it and need a refill sooner. And drug prescriptions should be reviewed by doctors on a yearly basis anyhow. If prescription systems have to deal with that, there is basically no benefit to be gained from having months and days line up precisely year after year.
The cost of the transition would not be insignificant. In the Western world, we've had two major calendar changes in the past 2200 years or so. The most recent one, the transition from the Julian calendar to the Gregorian calendar, lasted for about 400 years, as different countries transitioned at different times, with, I'm sure, plenty of friction caused by the lack of synchronization. Is it really necessary to go through all of that again?
Also, while this proposal would make holidays based on the solar calendar fall on the same day every year, it would do nothing for the holidays based on the lunar calendar. They would still drift around.
Reading their proposal on cato.org linked to from the article, it seems that a large part of their motivation is the synchronization of calendars for various financial instruments. But that doesn't require changing everyone's calendar; you can fix just the financial instruments, which already don't follow the ordinary calendar, without wreaking havoc on every other use of the calendar.
And I'm not sure how this extra week in December ever few years is supposed to help solve the problems with financial instruments. Under the current system, you need to deal with the fact that months may differ in length by up to 3 days, and that needs to be dealt with every month; in the new system, months would regularly vary by 1 day, but suddenly vary by another 7 days once every 5 years or so.
I think one of the reasons we've gotten ourselves into this mess is that we keep on trying to fit together different cycles of arbitrary length such that they match up exactly, which is impossible, so we add hacks on top of hacks to try to fix the problem. We try to make the cycle of days match the cycles of years, we try to make the cycle of months match the cycle of days (and years), and this proposal tries to shoehorn the cycle of weeks into that too, with a hack that adds an extra week every 5 or 6 years seemingly at random (while there is a regular rule for it, it's not as easily remembered as the Gregorian "leap year every 4 years, except for years divisible by 100, but an exception to that exception for years divisible by 400").
Instead of trying to do hacks to get all of these cycles to line up, why not move in the other direction and take the approach of having regular cycles at different frequencies that do not line up? You can have a financial calendar of 30 solar days (or whatever period is most convenient for you), a lunar calendar of one lunar month, the 7 solar day week, the tropical year that aligns with the seasons, the sidereal year that aligns with the orbit of the earth around the sun (which differs from the tropical year due to precession of the earth's axis). We have computers that can keep track of how all of these things line up when we care these days; instead of trying to simplify everything to fit together discretely with hacks added to fix it up, just let the computers deal with the precise details and allow each cycle to be simple and independent.
Now, moving to a single worldwide time standard (just use UTC for everyone for everyday use) seems to make a little more sense. While I understand the desire to make the hours line up with the solar day in a reasonably uniform way around the world, timezones (and daylight savings time) are an ugly hack that add a lot of cost and give you only a very rough approximation of what you are trying to achieve.