Submission on the Definition of Year 2000 Compliance
1.1 Earlier this year Standards Australia released a miscellaneous publication entitled: A Definition of Year 2000 Conformity Requirements(1). The definition states:
"Year 2000 conformity shall mean that neither performance nor functionality is affected by dates prior to, during or after the Year 2000.
(a) Rule 1 - No value for current date will cause any interruption in operation.
(b) Rule 2 - Date-based functionality must behave consistently for dates, prior to, during and after year 2000.
(c) Rule 3 - In all interface and data storage, the century in any date must be specified either explicitly or by unambiguous algorithms or inferencing rules.
(d) Rule 4 - Year 2000 must be recognised as a leap year in terms of handling both 29 February and day 366. (2)
1.2 A key element of both MP77 and its British counterpart is the fact that both definitions contain the statement that "neither performance nor functionality is affected". This means that if MP77 is adopted as the de facto standard in contracts it will mean that software must be 100% compliant as performance and functionality can be affected by a date error.
2. The Problem
2.1 If performance and functionality must not be affected in any way by a date error, a practical problem arises. For the past 50 years very few software programs have been produced free of errors. Further, over the same period software defect removal procedures have less than a 100% error detection and removal rate (DRR).
2.2 While state of the art procedures may approach a 100% DRR, the best practice benchmark appears to be approximately 95%.(3) Further, remediation procedures can introduce new defects into software while they are attempting to remove pre-existing defects.
2.3 The problems mentioned above are not isolated problems; they are industry-wide problems.
3.1 We submit that the Year 2000 Project Office supports certain amendments being made to MP77 to reflect industry practices and standards. The most pressing amendment is one relating to the "performance and functionality". Software developers and suppliers should not be required to give absolute warranties or guarantees regarding performance and functionality. Therefore, the following amendment should be inserted at the end of MP77:
"Notwithstanding this provision, no person producing or supplying computer hardware, computer software or programmable logic devices will be liable for loss or damage which occurs as a result of a date error in these products if at the date that the products are produced or supplied the risk of a data error occurring is not significant
Whether the risk of a date error occurring is significant is to be determined by reference to relevant industry standards at the time the product was produced or supplied (as the case may be)."
3.2 This amendment would provide greater certainty in the area of Year 2000 warranties because it expressly contemplates the importance of industry standards in assessing Year 2000 compliance.
3.3 Further, the first paragraph of MP77 could be amended by inserting the word "adversely" in front of the word "affected". Any remediation program, whether it utilises expansion tools or windowing utilities, is likely to produce an effect and therefore this amendment is logical.
3.4 We submit that certainty would be increased if the Year 2000 Project Office publicly supported the amendments that we propose to the widely accepted MP77 standard. Increased certainty will assist the courts if they are called on to interpret clauses modelled on MP77.
1. Hereafter referred to as "MP77".
2. This definition is modelled on this standard issued by British Standards late in 1996 entitled: DISC PD2000-]: A Definition of year 2000 Conformity Requirements.
3. See generally, C Jones, Software quality - analysis and guidelines for Success, international Thomson Computer Press, Boston, MA, 1997.