After Y2K, you thought it was safe to go back in the water when it came to date processing in application software... think again.

Back in 1999, "modern" software developers scoffed at those silly mainframe COBOL programmers from the 70's. Never mind their pocket protectors and white-shirt-and-tie getups: they lacked the foresight to consider that in less than thirty years their code would break, because their date fields with two-digit years would roll over like the odometer on an old car, flipping from "99" to "00" and turning date comparisons inside out. Is "000101" (January 1, 2000) greater than "991231" (December 31, 1999)? Depends on your definition of the word "greater".

How could those dummies write code so sloppily without concern for the future? What was wrong with them? Modern programmers use object-orientation, design patterns, IDE's, and hypercaffeinated coffee, we know better than to cause such problems!

Right?

Not so fast...

Just as the horror/sci-fi movie 28 Days Later gave way to its sequel, 28 Weeks Later, so our post-Y2K smugness could lead us to another horror movie taking place 28 (or so) years from now. (See the refactored movie poster to the right...)

Y2K "remediation" was big business in the late 90's, as organizations panicked because they feared the worst about their running software. Their fears (unlike the fears of those who predicted universal global turmoil and digital armageddon in the new millennium) were at least somewhat warranted—leaving the existing code untouched would result in problems where calculations and comparisons between dates were critical. So a number of remediation methodologies arose to fix the problem.

But Y2K problems weren't something that would suddenly appear at midnight on New Year's Eve 2000. Many software systems refer to dates in the future relative to the current date. Mortgages and some treasury notes have 30 year lifespans, so their maturity dates would be way off in the future, meaning that those systems might be affected long before the year 2000. So efforts to fix the potential problems started up way before the millennium.

One remediation method was the 28 year setback. The thinking behind this approach is that the calendar for this year is exactly the same as the calendar for 28 years ago. (This will not be true forever—it will break down after the year 2100, which by Gregorian rules will not be a leap year, though 28 years before, the year 2072, will be.) The trick is to subtract 28 years from all stored dates, do math on the offset date values, and add 28 years to those values when presenting them.

There have been other approaches, like date windowing, which selects a two digit number (e.g., 40) as a threshold—less than 40 means you're talking about a date after the year 2000; greater than 40 means it's in the 1900's. But you get the idea: "don't fix the problem, put it off" is the mantra here. Your children will be better programmers than you were and will be able to fix everything.

Or will they? Is UNIX, for instance, immune from those IBM mainframe problems?

Nope.

The "epoch", the moment at which time begins for UNIX systems, is midnight GMT on January 1, 1970. Since dates are calclulated as seconds since the epoch, the maximum viable date will depend on how dates are actually stored. Since in fact they are stored as 32-bit integers, the largest number that can be used is 231 seconds, and 231 seconds after "01/01/1970" occurs some time on January 19, 2038... give or take (depending on your time zone).

So here IBM mainframes may have UNIX beat. Rumor has it that that IBM mainframe clocks won't give out until... the year 2041.

A song keeps running through my head:

In the year 2828,
if software processes dates,
if programs can relate
they may...
DateOutOfBoundsException: overflow, overflow!
Danger, Will Robinson!

A couple of the links below are lists of "critical dates" in the near future which may be affected by one or more of these date-related problems. Mark them on your calendar: if you stocked up on toilet paper and canned goods for your bunker back in '99, you may want to do so again.