Hacker News new | comments | show | ask | jobs | submit login

Have they come up with any estimate of the global cost of the switch, and compared that to the benefit of the new calendar? It seems to change a bunch of stuff, and add a complicated new "leap week", for no particularly good reason. Yeah, it might reduce the cost of printing calendars slightly, though a lot of people use new calendars yearly so they can write on them, and a lot more just use their computer.

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.




Timezones are not an ugly hack.

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 ran into a big problem with timezones when I was in the Navy.

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.


It's wholly due to bad programming. Put the timestamps in epoch time - that never changes, then read them back in whatever your current timezone is. If you're in a situation like you were where timezones change frequently, you'll also need to record the timezone when the entry was made for reference.

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.


Best practice - whatever time zone the people are using, keep the internal time stamps on a single time zone (usually UTC). Then just convert the times from and to the local zone for input and display, respectively.


> keep the internal time stamps on a single time zone (usually UTC)

Or UNIX time. While not monotonically increasing (it has issues with UTC leap seconds), it's pretty good.


Just store all the dates and times in UTC, then convert to local time


With time zones, you have to know which time zone you're in and set your watch accordingly. With no time zones, you have to know what time local noon is and interpret your watch accordingly. The amount of information required, and the difficulty of using it, appears to be the same to me.


For the common case of infrequent changes in time zones (relative to the number of times one does a time lookup or talks about time), I think what we use now is less difficult to use. You only have to make the adjustment once, instead of every time you talk about times.


It seems to me like the opposite is the case. I have to coordinate times across time zones way more often than I actually travel (for online meetings and such). If there was a single time zone, I'd never have to make adjustments for those, and only adjust things when traveling.


The problem there is that in a lot of cases you pretty much use timezones implicitly anyway. If you want to call someone in China from North America, for instance, if it's 3pm where you are, you might know that it's 3pm in China (in this hypothetical no-timezone world), but that still doesn't tell you if it's a reasonable time to call. You have to think, "Well, people in China usually work from time X to time Y, so their time X is my 9am, which means the offset is Z, which means 3pm in China is equivalent to my 3pm + Z, which means it is/isn't a good time to call."

You basically have to reinvent timezones every time you make any kind of calculation involving people in another timezone.


Right, so you do the same calculations in those cases, but, when someone proposes meeting at 3PM, you don't have to do any conversions. Some upside, no downside, unless I've missed something.


OK. So you are traveling and your plane goes at 15:00 (with this hypothetical clock, I would drop the PM stuff). Do you have time for lunch beforehand? Should you try to?

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.


Your travel examples are indeed more difficult, but I travel much less than I coordinate times across time zones, and I suspect most other people do as well, even if it's something as simple as calling family in another state.

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"?


>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?

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.


Mesoamerican (mostly known through Mayans, but others used the same calendar) had two ways of doing that.

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)


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.

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 UN is not a "global governing body." It has no real power; and it doesn't deal with things like calendar standards. And it would take a lot more than "sign off" from some global standards body to get people to actually switch. It would require completely re-writing every piece of date handling software ever.

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.


Sigh. You know what, I actually tried to find a better term than "governing body" but at the end of the day, I didn't really find an alternative that wouldn't immediately get some peanut objecting to its exactness, so I went with governing body. Thankyou for being the peanut. So, international politics 101. The UN is a body whereby the nations of the planet can get together and discuss global problems and their solutions. This type of body did not exist 1500 years ago. Yes, like any reasonably well-educated adult on the planet I'm aware that the UN can't make laws, and couldn't enforce them if it did. But in the real world there are other means available to the UN to pressure member states to do the right thing. If 99% of nations voted for a new calendar, the remaining 1% are going to look pretty silly if they stay on the old calendar.

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.


None of which ultimately matters. The United States, which for better or worse has significant influence on the world (UN included) could not even switch to the metric system on a time frame and manner of its own choosing. How well do you think we could transition from one system of time- and date-keeping to another, which is arguably more integral to people's lives than other types of measurement, especially when done by fiat through an external body?

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.


Thank you for making such a good argument against his ridiculous straw man comparing the transition pre-globalization to a transition nowadays.


> 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.

The UN doesn't have that authority, either politically or morally. http://en.wikipedia.org/wiki/Durban_Review_Conference


>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.

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.


"""Have they come up with any estimate of the global cost of the switch, and compared that to the benefit of the new calendar?"""

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.


You forgot to discount future benefits. Interest is exponential, meaning bounded gains that last forever have finite present day value.


> 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?


Did you actually read the article or is this: "Yeah, it might reduce the cost of printing calendars slightly, though a lot of people use new calendars yearly so they can write on them, and a lot more just use their computer." made to be a straw man on purpose?

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."


I read the article. Most of the arguments seemed to be pretty dubious, like the "cost of printing the calendars" argument. I addressed the one that seemed most relevant, the one about financial calculations, by pointing out that it would be possible to set a different standardized calendar for just financial instruments without changing the calendar for everything else.

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.




Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | DMCA | Apply to YC | Contact

Search: