White SW Computer Law
Intellectual Property, Information Technology & Telecommunications Lawyers
Melbourne Office - PO Box 452, COLLINS STREET WEST Victoria 8007 Australia
Sydney Office - GPO Box 2506, SYDNEY New South Wales 2001 Australia
Telephone: Melbourne Office - +61 3 9629 3709 Sydney Office - +61 2 9233 2600
Facsimile: Melbourne Office - +61 3 9629 3217 Sydney Office - +61 2 9233 3044
Email: wcl@computerlaw.com.au Internet: http://www.computerlaw.com.au

User Tools

Site Tools



Whether you are the customer using the software or the supplier an/or programmer, should a Y2K error occur in your software, it will be important to keep detailed notes of the circumstances of how the error occurred. Should a dispute arise, it will be important to be able to demonstrate from the recorded information how you think the fault arose. For example, faulty hardware or third part software may cause Y2K compliant software to appear as if it has a Y2K error.

The key aspect to reporting errors is locating the fault. In many cases, the user will not have the expertise to locate the fault, so it is important to record the following information each time a fault occurs to allow analysis of the problem by someone who was not present when the error occurred.

  • A general description of the fault
  • The symptoms of the fault
  • What happened before, during and after the fault
  • The time and date of the fault
  • The program reporting the error (including release and update levels)
  • The program(s) running at the time of the fault (including release and update levels)
  • The operating system including release levels and update levels
  • The error number reported and any other relevant information displayed. Error registers etc
  • Collect memory dumps, audit logs, error logs, message logs, transaction logs and any other information no matter how irrelevant. In serious failures an entire tape backup (if possible) should be taken for later evidence.
  • A complete list of all hardware components including part numbers and bios levels
  • Has the operation worked before?
  • If so, what has changed?
  • Can the fault be reproduced?
  • Version control can be critical to fault isolation and determination and it is important that versions are appropriately marked for both correcting the fault and subsequent possible litigation.

You should report faults as soon as possible. Your supplier may also have further information, which is required to be collected and you should ensure that you are familiar with their requirements.

The 1994 decision in the UK matter of St Albans v City and District Council and International Computers Ltd, was that the fact that the faulty program printed all zeros on a printed report (indicating a fault) was not sufficient to relieve the supplier from its subsequent negligent misstatement that the figures from the screen could be adequately relied upon. However, the fault in this matter was expressly reported to the supplier for attention.

Customers should ensure that they report any Y2K errors as soon as possible, with as much detail as possible to give the supplier an opportunity to correct the error before loss and damage is incurred and suppliers need to ensure that they act quickly upon any reported Y2K errors to minimise any potential loss and damage suffered by the customer.

For further information see:



www.computerlaw.com.au © White SW Computer Law 1999 This article is a guide only and should not be used as a substitute for proper legal advice, readers should make their own enquiries and seek appropriate legal advice.

  © White SW Computer Law 1994-2019. ABN 94 669 684 644. All Rights Reserved.
  Liability limited by a scheme approved under Professional Standards Legislation
  This website is a guide only and should not be used as a substitute for proper legal advice.
  Readers should make their own enquiries and seek appropriate legal advice.
  For legal advice please email wcl@computerlaw.com.au