The following is reproduced with the kind permission of

MTB logo

September/October 1997, pp 38-47

Digital doomsday

A business survival guide to the year 2000 - Part 1

by Geoff Palmer

click here for Part 2 of this article

Six critical dates

United party leader Peter Dunne's year 2000-compliance bill (which is still to go before Parliament) identifies six key Y2K-related dates:

  • 01/01/99 and 09/09/99 are sometimes attached to computer files to signify the file is to be kept forever or is the master backup to which incremental changes should be added.
  • 31/12/99 is sometimes used as a "boundary marker" that will cause some systems to stop or simply revert to an earlier date. Many (especially older) PCs will flip back to 1980. Some Unix systems will return to 1970.
  • 01/01/00. The biggie. Year 00 will mean the collapse of many existing systems or, more frighteningly, a subtle change in the logic paths followed when comparisons between dates are made.
  • 29/02/00 which many systems will treat as 01/03/00 since the determinant of a leap year - that the year is divisible by 4 - fails to work correctly.
  • 31/12/00. Again, some systems won't be expecting a 366th day for an apparent non-leap year.

Who could be liable?

Company directors

  • Breach of fiduciary duty of care, reckless trading

Vendors of non-compliant products

  • Breach of warranty
  • Breach of the Sale of Goods Act (goods are unfit for the purposes for which they were supplied)
  • Negligence causing foreseeable damage (failing to exercise reasonable care in development)
  • Fraud (knowingly selling a faulty product)

Software maintenance contractors

  • Breach of contract (failing to adequately maintain the system)

Upstream or downstream customers, vendors, suppliers or distributors who aren't Y2K ready

  • Negligence causing foreseeable damage

How did we get into this mess anyway

  1. Shorthand. Ask anyone to scribble down their date of birth and there's a 95% chance they'll give it to you as dd/mm/yy (or mm/dd/yy if they're American). So don't blame programmers for something most of us do.

  2. Space. At the dawn of business computing in the 1960s, the main data entry method was the 80-column keypunch card. Subtract eight characters for control information and you're left with cramming as much data into 72 slots as possible. Waste an extra two on the year? Forget it.

  3. Surprise. No one honestly expected that the systems they were writing in the 60s and 70s would see out the century. There was certainly no precedent for it, and from the hype of the day we'd all be flying hover-cars and have robotic home help by then. In the Think Big 80s these old crocks were going to be swept away by the huge new systems we were writing (but never finished) and then suddenly business just became a matter of survival.

  4. Survival. Although programmers have known about the problem from the start and the public warnings have been going on since Peter de Jager's famous piece called Doomsday appeared in Computerworld in late 1993, business survival is rarely focused on such long-term intangibles. Squeezing more profit from an intransigent market or simply staying alive have been paramount. Who wants to throw money at a project that has no visible payoffs?

  5. SEP. In the third volume of Douglas Adamsí Hitchhiker's Guide to the Galaxy series he describes a SEP as being "something that we can't see, or don't see, or our brain doesn't let us see, because we think that it's somebody else's problem. That's what SEP means. Somebody Else's Problem. The brain just edits it out, it's like a blind spot".

    Example: About 18 months ago I was contracted to redevelop some authorisation software for a major financial institution. When I commented to the project manager that the code wouldn't be year 2000-compliant but that I could make it so in a couple of hours he replied, "Nah, don't bother. It won't make any difference Ďcos the rest of the systemíll be [useless] by then anyway." SEP.

What about insurance?


    Won't some of the costs of Y2K systems failure be covered by insurance?
    No. Most insurance policies don't cover the loss of data. Your hardware is covered if your offices burn down but your data, the most valuable component, isn't. (Besides, how can you have lost your data if it's all still there on backup tapes? You may not be able to use it, but it's still there.)


    What about special EDP riders and the like?
    Again no. Most specifically exclude programming errors and omissions.


    How about if we are sued because our faulty data wrecks a customer's system?
    It depends on the policy and, to some extent, the nature of the claim. Most standard business insurance policies only cover tangible losses like property damage or physical injury, while others cover more general liabilities, including such intangibles as loss of data. Check with your broker - now - just in case.

Misnomers and misconceptions

  • Some sources are referring to the year 2000 problem as a "virus". It most certainly isn't a computer virus - a piece of self-replicating code that's transmitted by compute interaction - and this sort of talk will only muddy the waters further. There are bound to be real viruses triggered by the change of century - a situation that will simply confuse the real year 2000 issue.

  • Tradition has it that if the year is evenly divisible by 4, it's a leap year. So year 0 divided by 4 .... But there's a bump in leap year logic every 400 years - and we're heading for one right now. New centuries are ignored unless they're evenly divisible by 400. So yes, there really will be a 29/02/2000.

  • (For pedants only) It's not the start of a new century and a new millennium, it's merely the last year of the last century of the old one. (Count to 100. Did you start counting at 1 or 0?)

And now a little good news - sort of ...

According to a Microsoft press release, "Over the past 20 years (starting with the first release of MS-DOS), Microsoft has consistently incorporated the capability to handle four digit dates into its products. As a result, Microsoft's products can store and handle calculations based on dates in the 1900s and the 2000s."

But that doesn't mean applications written using Microsoft products will automatically conform. Nor does it mean that your PC won't revert, as many do, to 1980 at the stroke of midnight.

Why let vendors off the hook?

Imagine if it was discovered that every car in the world was going to break down on a certain date. People would be up in arms and the manufacturers would be pressured into providing a no-cost fix. Yet somehow the information technology industry has escaped what could be considered the biggest case of planned obsolescence ever. Customers just shrug their shoulders and either roll up their sleeves and start poking around under the bonnet, or pull out their cheque books and start writing.

That's the spin put on the year 2000 problem by Bennett Medary of project management and technology consultants The SIMPL Group.

"Why," he asks reasonably, "has government and the business community let the IT industry off the hook?'

He says that, technically, a vendor is liable for the usability of his product. If it won't work after a certain date, that's not the customers fault. There's a growing body of case law - particularly from the UK - to back up this assertion, though it's yet to be tested in New Zealand.

It's going to depend on the wording of your warranties, site licences and maintenance agreements but, if you're faced with a megabuck fix-up bill, it could be well worth the effort.

and now you can to link to ...?

click here for Part 2 of this article

Year2000 New Zealand home page
Computerworld New Zealand's home page
National Business Review's home page

Copyright © Wilson White Group and Computerworld, 1997