Some folks think I’m crazy for continuing to include Y2K-type language in my software licenses.
[Special appearance of the Wayback machine: For those of you who don’t even know what I’m talking about, back in the day, we were concerned that software was going to stop working on January 1, 2000. The fear was that since some sloppy programmers wanted to save computer memory by shortening dates to only two-digits, that once the year moved into 2000, date calculations would no longer work. Thousands of programs had to be tested and patched. Almost every organization did some sort of Y2K audit to figure out whether they were going to have problems.]
Oh, and did I mention that many software vendors were charging for the privilege of getting replacement software that wasn’t coded in this sloppy manner? Yep. Not to mention the fact that the memory problem that precipitated the sloppy coding was solved somewhere around the mid-80s (and even if you want to balk and say that this type of memory problem wasn’t fixed until the early 90s, we’re still talking about having more than 10 years to fix, or prevent, the problem).
So, in typical contractual knee-jerk manner, the legal/contract community’s response was to start including contract language that said that a computer program would work properly after 1/1/2000. At first, this was problematic, as vendors sometimes didn’t really know whether their application would work correctly. Then they were concerned about the interaction between their application and other people’s applications. Ahhh… and let us not forget those lazy vendors who didn’t fix the application properly… they just patched it to still use two-digit years, but make some sort of logical calculation that if the 2 digits were between 0 and 40 (or so), it would be read as 2000 – 2040, and if the 2 digits were between 41 and 99, it would be read as 1941 and 1999.
Well, I never stopped including language in my contracts that addresses this problem. Of course, I don’t specify that I’m talking about the Y2K problem specifically – I just have as part of my warranty language that:
“at no additional cost to Licensee and without human intervention, the Software will correctly recognize and correctly process data and formulas relating to the year 2000 and beyond (including arithmetic, comparison, sorting, day-of-week and day-of-year functions), will produce expected results (including correct leap year calculations) and will provide all such date-related data and formulas used by other applications in a format that will permit the correct recognition of dates by the other applications”
Most vendors don’t even blink at this anymore. In fact, I’m not even sure they think about it at all. But for the last ten years or so, I’ve included something similar.
And now it’s time for me to reap the rewards. For I knew a little-known fact (at least in the contract/legal community, that is)… the Y2K problem was a toll-booth on this highway. One of many similar issues. The next one is coming in 2038.
News: Saturday 19 Janurary 2008 is coming soon: this date is exactly 30 years before the bug. Will 30-year bonds and retirement schemes be affected? Let’s wait and see.
The year-2038 bug is similar to the Y2K bug in that it involves a time-wrap problem not handled by programmers. In the case of Y2K, many older machines did not store the century digits of dates, hence the year 2000 and the year 1900 would appear the same.
Of course we now know that the prevalence of computers that would fail because of this error was greatly exaggerated by the media. Computer scientists were generally aware that most machines would continue operating as usual through the century turnover, with the worst result being an incorrect date. This prediction withstood through to the new millennium. Affected systems were tested and corrected in time, although the correction and verification of those systems was monumentally expensive.
There are however several other problems with date handling on machines in the world today. Some are less prevalent than others, but it is true that almost all computers suffer from one critical limitation. Most programs work out their dates from a perpetual second counter – 86400 seconds per day counting from Jan 1 1970. A recent milestone was Sep 9 2001, where this value wrapped from 999’999’999 seconds to 1’000’000’000 seconds. Very few programs anywhere store time as a 9 digit number, and therefore this was not a problem.
Modern computers use a standard 4 byte integer for this second count. This is 31 bits, storing a maximum value of 231. The remaining bit is the sign. This means that when the second count reaches 2147483647, it will wrap to -2147483648.
The precise date of this occurrence is Tue Jan 19 03:14:07 2038. At this time, a machine prone to this bug will show the time Fri Dec 13 20:45:52 1901, hence it is possible that the media will call this The Friday 13th Bug.
So… might I suggest that you include Y2K related language now? Sure, some folks might think you’re a little loopy. But isn’t our job to protect folks from the risks they don’t understand?