The Next Date Problem After Y2K
With all the commotion surrounding Y2K, we forgot to stand back and count our blessings. As every programmer knows, calculating leap year by dividing the date by four is pretty standard coding. If there is no remainder, it is considered a leap year, and an extra day, leap day, is added to February.
There is, however, an exception to this rule. This exception doesn't come into play, lucky for us, with Y2K. If it did, we'll be modifying leap year calculations as well as enlarging date fields.
If the advent of computers had been 100 years earlier or a century later, if this was the Year 1900 or 2100, for example, we would need to adjust our standard leap year coding. We lucked out with the Year 2000.
As good fortune will have it, the Year 2000 is a leap year, regardless of the fact that it's evenly divisible by four. A century year, a year 00 with its century prefix, is considered a leap or bissexitile year only if it is evenly divided by 400, not by 4.
The year 1900, although it is evenly divisible by four, was not a leap year; there was no Feb. 29, 1900. The year 2100 is also not bissexitile because it isn't divisible by 400, though it is divisible by 4.
2100 is another date problem looming on the horizon, albeit the far horizon. The current Y2K hullabaloo is only specific to the Year 2000 itself. Our systems and applications still can not properly process centuries unless they also account for the century leap anomaly.
This is not just an AS/400 problem but, like the Y2K crisis, a world-wide condition. Although it might not have the widespread crucial and critical implications that Y2K has, the century leap exception, if not properly handled, will have adverse effects in critical applications like banking where savings accrual rates are determined by dates. Just ask any banker his thoughts of paying an extra days' unearned interest on his accounts, or anyone else for that matter who holds a credit card, and one begins to understand the unholy premise of the Century 21 problem.
As we progress our systems to accept and process centuries, one more step up the software evolutionary ladder is to update leap year calculations to successfully account for the exceptional condition caused by century years.
It would be interesting to see how the next generations of programmers handle this date problem. See if they learned from the Y2K crisis. Would they wait until the last moment to fix it, the type of laissez-faire attitude that brought us the Y2K crisis? Or would they start coding for the century leap in applications developed, say, after 2050? And would they keep this coding in their programs even though it is only executed one year out of a hundred? Would they delete it and bring it back at the start of every century? A Year 00 patch, so to speak, to be run at century end and documented in the run book after Year End Jobs?
2050 is another problem date since it is arbitrarily used by some applications to affix the current generational date problem. Year values of 50 - 99 are given 19 as the century prefix and values of 00 - 49 are labeled with 20. This Y2K temp fix will itself need to be fixed in the immediate years preceding 2050, the notorious Y2.5K problem. This will probably be a good time as any to make the Century Leap fix as well.
Of course, maybe by that time, all software will be calling date validation routines online from a Library of Congress standard. Nonetheless, even this approach isn't foolproof.
Undoubtedly, there will always be a programmer somewhere in a cave coding his own applications. Hence we should all be aware of the exceptional condition caused by the century leap. The fact that we have a 100+ years before this problem hits is a benevolent stroke of luck. As the old adage has it, it's all in the timing.
A grunt programmer/analyst with the Commonwealth of Pennsylvania who has to go in and fix these things, Essig was surprised to find little information concerning the century leap exception mentioned in the literature. Needless to say, his own shop, though Y2K compliant, is still leap year challenged.