Dick Henry writes here about a new proposal for a universal calendar. His idea avoids interpolating a special year-day, an issue that has plagued previous proposals. Religious groups that worship a holy day every seven days hate the interpolated day, because it implies shifting the lord’s day from Sunday one year to Saturday the next, and so on.
The Hanke-Henry Permanent Calendar interpolates a whole week, every five or six years. It does not monkey with the lord’s day calculations, and it has the fascinating side effect that any memorable day (such as your birthday, or July 4th) will henceforth always fall on the same day of the week. Henry proposes that we commence using this calendar in 2012.
A better idea would be plan now, to start using the calendar in 2062. If a great majority of people like it, that is. Here’s the problem:
On the web page I linked to, there’s a FAQ, including this item:
14.) Won't this whole exercise be costly?
It will be about as costly as the Y2K problem was.
Henry betrays a woefully poor understanding of computers in this answer. The challenge of Y2K was to find every computer program that would calculate the date wrong in the year 2000. If that calculation could cause any real problem, then the program had to be changed. A great deal of development effort went into making sure there would be few problems, and the most evident result was that computer departments did very little real development that year. The Y2K problem siphoned off a lot of potential creativity. Companies had less money to buy new hardware and software, because their staffs were working on Y2K. The Y2K cost was great enough to produce a poor year for the computer industry.
Shifting to the Hanke-Henry calendar requires a different kind of effort. Every single program that needs to calculate dates will be wrong. Every single one will have to be modified or replaced. Every program that keeps track of the “week of the year” will have to be changed to handle the 53rd week that will appear in some years.
There is only one easy way to introduce a new calendar, and that is to assume it will go into effect after 99.99% of non-complying programs are no longer in use. We can issue straightforward software libraries that make all necessary date calculations for both the current way and some new way, and use these libraries in all newly developed programs, from 2012 on. We can “throw the switch” to the new calendar when almost all old programs are dead. Fifty years of waiting should do it.
(The easy way to reform the calendar, if it was ever going to be formed again, was before we had computers.)
NOTE 1:Today, changing the way the date is calculated implies changing and replacing a lot of hardware, as well as software. Much hardware has programs burned into it, and some of that software does date calculations.
NOTE 2:Many people claim that the Y2K effort was overblown and mostly unnecessary, because there were, in fact, few problems when we entered the year 2000. My own feeling is that it was the great effort to avoid Y2K problems that produced such smooth sailing. But regardless of how you felt about the Y2K effort, this calendar proposal requires more effort, not less; because we KNOW that no computer program in production today knows how to handle the proposed calendar.
NOTE 3:The Y2K problem did not require republishing any books. A great number of books have information that depends on calendar dates, and many of these will become misleading and incorrect.
The Hanke-Henry Permanent Calendar interpolates a whole week, every five or six years. It does not monkey with the lord’s day calculations, and it has the fascinating side effect that any memorable day (such as your birthday, or July 4th) will henceforth always fall on the same day of the week. Henry proposes that we commence using this calendar in 2012.
A better idea would be plan now, to start using the calendar in 2062. If a great majority of people like it, that is. Here’s the problem:
On the web page I linked to, there’s a FAQ, including this item:
14.) Won't this whole exercise be costly?
It will be about as costly as the Y2K problem was.
Henry betrays a woefully poor understanding of computers in this answer. The challenge of Y2K was to find every computer program that would calculate the date wrong in the year 2000. If that calculation could cause any real problem, then the program had to be changed. A great deal of development effort went into making sure there would be few problems, and the most evident result was that computer departments did very little real development that year. The Y2K problem siphoned off a lot of potential creativity. Companies had less money to buy new hardware and software, because their staffs were working on Y2K. The Y2K cost was great enough to produce a poor year for the computer industry.
Shifting to the Hanke-Henry calendar requires a different kind of effort. Every single program that needs to calculate dates will be wrong. Every single one will have to be modified or replaced. Every program that keeps track of the “week of the year” will have to be changed to handle the 53rd week that will appear in some years.
There is only one easy way to introduce a new calendar, and that is to assume it will go into effect after 99.99% of non-complying programs are no longer in use. We can issue straightforward software libraries that make all necessary date calculations for both the current way and some new way, and use these libraries in all newly developed programs, from 2012 on. We can “throw the switch” to the new calendar when almost all old programs are dead. Fifty years of waiting should do it.
(The easy way to reform the calendar, if it was ever going to be formed again, was before we had computers.)
NOTE 1:Today, changing the way the date is calculated implies changing and replacing a lot of hardware, as well as software. Much hardware has programs burned into it, and some of that software does date calculations.
NOTE 2:Many people claim that the Y2K effort was overblown and mostly unnecessary, because there were, in fact, few problems when we entered the year 2000. My own feeling is that it was the great effort to avoid Y2K problems that produced such smooth sailing. But regardless of how you felt about the Y2K effort, this calendar proposal requires more effort, not less; because we KNOW that no computer program in production today knows how to handle the proposed calendar.
NOTE 3:The Y2K problem did not require republishing any books. A great number of books have information that depends on calendar dates, and many of these will become misleading and incorrect.
2 comments:
Your concerns have a global outlook + solution. My problem is this: Who wants their birthday to be on a Tuesday every frickin year of their life?
Good point. I like to have a roving birthday.
- PB
Post a Comment