The year of living dangerously
3 November 1997
6 May 2014
8 May 2014
7 April 2014
25 September 2013
2 October 2013
It seems that up until recently, the problems posed by moving into the next millennium have been a blind spot for most people in the world of IT. The problem, now being described variously as "the year 2000 issue" and the "millennium bomb" has finally been identified.
In a nutshell, the issue is this: most software programs have been written in such a way that the date field is limited to two characters for each day, month and year, so typically 1996 will appear as 96. This means that the year 2000 will be represented by 00.
However, many programs use 00 as an error code, for example, or work by taking one date away from another, so taking 96 away from 00 will result in an error or a minus figure. Solutions so far identified, include coding around the problem or expanding the field size, but the cost of such solutions is potentially very large.
Speak to a different IT professional and you will get a different estimate of the cost, but for illustrative purposes a source recently calculated that an organisation the size of a local authority with approximately 60 per cent of its systems affected will have to put 109 man-years' worth of effort into solving the problem, clearly not an insignificant amount.
The millennium time bomb is interesting in legal terms because the cost implications mean that customers will be looking to their suppliers to fix and to foot the bill and suppliers will be looking to their customers to pay for their remedial work.
Clearly arguments over liability for the cost of fixing the problem will arise. In practical terms all organisations ought to be performing technical, contractual and intellectual property audits.
The technical audit will establish which systems and software are affected by the millennium bomb. The contractual audit will check the terms of the agreements relating to the affected systems and software to establish whether, notwithstanding the fact that the agreement was not drafted with the millennium bomb in mind, the terms can be used to apportion liability. In this regard, definitions of 'faults' and provisions providing for preventive maintenance will assume great importance, as will the interpretation of existing warranties such as those covering fitness for purpose.
The IP audit will help to determine whether a customer, in circumstances where there is an impending fault, can access the source code to the affected software to effect a fix either himself or via a third party with the requisite skills.
Of course, existing contracts are only half the story and it is important to be proactive to ensure that all new contracts entered into between now and the millennium and, in particular, those that will straddle the millennium can cope with date change. Organisations will need to focus on introducing new warranties to ensure that a system is year 2000 compliant, to add year 2000 compliance to the list of acceptance criteria and to explicitly make sure that access to source code held in escrow will be triggered by non-compliance.
As Thomas Fuller said in 1732: "He that fears not the future may enjoy the present"; to avoid fear of the future organisations can either ignore the problem or deal with it head on, we suggest the latter approach.
Task Force 2000
The UK is finally seeing some progress on the millennium bomb. The DTI, in conjunction with the CBI and the CSSA, has set up a body known as Task Force 2000, which intends to act as a focal point for dealing with the year 2000 problem in the UK.
As part of that process, Task Force 2000 has adopted a "definition of compliance" drafted by this firm.
This reads that year 2000 compliance shall mean:
"The ability for continued normal use of [a system/item of software] such that neither the performance nor the functionality of the [system software] will be affected by any changes to the date format [as defined below] caused by the advent of the year 2000.
(i) Year 2000 compliance shall mean that no value for current date will cause any interruption in the operation of the [software/system];
(ii) all manipulations of time-related data will produce the desired results for all valid date values within the application domain and in combination with other products, prior to, through and beyond the year 2000;
(iii) date elements in interfaces and data storage will permit specifying the century to eliminate date ambiguity without human intervention, including leap year calculations; and
(iv) where any date element is represented without a century, the correct century shall be unambiguous for all manipulations involving that element."
This definition is intended to represent the interests of users of affected software and has been circulated to representatives of vendor organisations so users and vendors can agree on a definition of year 2000 compliance.