June 21, 2018

Perl and the Y2k problem - page 3

Doomsayers everywhere

  • October 20, 1999
  • By Tom Christiansen
Unfortunately, hardware and software fixes do not help. The real problem is the wetware. That's right: the defect lies not in our computers, nor in their programming, but rather in ourselves.

Most of the time that people think about dates, they use only the final two digits of the year. They write it on checks. They write in family Bibles. You hear someone casually say, ``I remember back in '65,'' or ``the Generation of '98 had their collective consciousness shaken to the roots by their astonishing defeat to the Americans in the Caribbean,'' and you're just supposed to know what they mean. Just which 65 is that? Assuming a living speaker, it provably has to be 1965. But just which 98 was that? Why, it was not the current year, but rather way back in 1898, when Spain lost the remainder of their decrepit empire to those upstart New Worlders and subsequently succumbed to a national soul-searching that permeated the national literature of that age. In both cases, you resolve the ambiguity by inferring the full year from the context, of course. But if you don't have that context, then you just have to guess. And remember: computers make notoriously bad guessers.

The most horrifying aspect of all this is that even with a perfectly accurate and working computer program, one that is obviously ``Y2K compliant'', you are still in big trouble. Take for example, the famous Unix cal program. Let's check out the current month.

            $ cal 2 98
                 February 98
            Su Mo Tu We Th Fr Sa
                         1  2  3
             4  5  6  7  8  9 10
            11 12 13 14 15 16 17
            18 19 20 21 22 23 24
            25 26 27 28

Hold on. What was that? Isn't Valentine's Day is supposed to fall on Saturday, not Wednesday, this year? Oops; wrong millennium! What you really meant to type was:

            $ cal 2 1998
                February 1998
            Su Mo Tu We Th Fr Sa
             1  2  3  4  5  6  7
             8  9 10 11 12 13 14
            15 16 17 18 19 20 21
            22 23 24 25 26 27 28

As you see, it doesn't matter whether the programs are compliant, because the humans using them are not! Fixing the programs is certainly a necessary step, but far, far from sufficient. You can certify every single program in existence, and it still will not be enough for safety. Until such time as the teeming billions of people in this world -- or even just the many millions using computers -- are all similarly certified, and warranted not to forget, there can be no safety. And that's not going to happen.

To seek legally binding statements that a particular program cannot be intentionally or unintentionally misused is nothing but a witch hunt doomed to fail in its ultimate goal of protecting you and yours. You cannot avoid the fact that there will always be cluefully-challenged users and programmers out there, or even persons of clue who occasionally have a memory lapse. You cannot find them, you cannot blame the tool or language, and you cannot protect yourself from them. Every time a human being thinks about a year in terms of just two digits, the problem reasserts itself. And no one has yet figured out how to fix the wetware.

Most Popular LinuxPlanet Stories

We have made updates to our Privacy Policy to reflect the implementation of the General Data Protection Regulation.