page_title: Year 2000 problem
hierarchical_section_title: Year 2000 problem
caption_attribution_description: Français&#160;: Bug de l'an 2000&#160;: la pendule indique Janvier 1900 au lieu de Janvier 2000 English: Year 2000 Bug： the sign indicates January 1900 instead of January 2000
context_page_description: The Year 2000 problem, also known as the Y2K problem, the Millennium bug, Y2K bug, the Y2K glitch, or Y2K, refers to events related to the formatting and storage of calendar data for dates beginning in the year 2000. Problems were anticipated, and arose, because many programs represented four-digit years with only the final two digits – making the year 2000 indistinguishable from 1900. The assumption of a twentieth-century date in such programs could cause various errors, such as the incorrect display of dates and the inaccurate ordering of automated dated records or real-time events.
  In 1997, the British Standards Institute developed standard DISC PD2000-1 defining "Year 2000 Conformity requirements" as four rules:
  No valid date will cause any interruption in operations.
  Date-based functionality must behave consistently for dates prior to, during and after year 2000.
  In all interfaces and in all storage, the century must be unambiguous, either specified, or calculable by algorithm.
  Year 2000 must be recognised as a leap year.
  It identifies two problems that may exist in many computer programs.
context_section_description: The Year 2000 problem, also known as the Y2K problem, the Millennium bug, Y2K bug, the Y2K glitch, or Y2K, refers to events related to the formatting and storage of calendar data for dates beginning in the year 2000.  Problems were anticipated, and arose, because many programs represented four-digit years with only the final two digits – making the year 2000 indistinguishable from 1900.  The assumption of a twentieth-century date in such programs could cause various errors, such as the incorrect display of dates and the inaccurate ordering of automated dated records or real-time events.
  In 1997, the British Standards Institute (BSI) developed standard DISC PD2000-1 defining "Year 2000 Conformity requirements" as four rules:
  No valid date will cause any interruption in operations.
  Date-based functionality must behave consistently for dates prior to, during and after year 2000.
  In all interfaces and in all storage, the century must be unambiguous, either specified, or calculable by algorithm.
  Year 2000 must be recognised as a leap year.
  It identifies two problems that may exist in many computer programs. First, the practice of representing the year with two digits became problematic with logical error(s) arising upon "rollover" from xx99 to xx00. This had caused some date-related processing to operate incorrectly for dates and times on and after 1 January 2000, and on other critical dates which were billed "event horizons". Without corrective action, long-working systems would break down when the "... 97, 98, 99, 00 ..." ascending numbering assumption suddenly became invalid.
  Secondly, some programmers had misunderstood the Gregorian calendar rule that states years that are exactly divisible by 100 are not leap years, assuming that the year 2000 would not be a leap year. In reality, there is a rule in the Gregorian calendar system that states years divisible by 400 are leap years – thus making 2000 a leap year.
  Correcting all of this, however, was not the largest part of the problem. By 1997, AT&T had estimated that "60% of the time and money needed for its total compliance efforts" would be devoted to testing the source code changes made to address the issue.
  Companies and organisations in some countries, but not all, checked, fixed, and upgraded their computer systems to address the anticipated problem. Very few computer failures were reported when the clocks rolled over into 2000.
caption: An electronic sign at École centrale de Nantes incorrectly displaying the year 1900 on 3 January 2000
exif: {"Image XResolution": "1", "Image YResolution": "1", "Image ResolutionUnit": "Not Absolute", "Image DateTime": "2000:01:03 12:09:05", "Image YCbCrPositioning": "Centered", "Image ExifOffset": "134", "GPS GPSVersionID": "[2, 2, 0, 0]", "GPS GPSLatitudeRef": "N", "GPS GPSLatitude": "[47, 14, 284065/5347]", "GPS GPSLongitudeRef": "W", "GPS GPSLongitude": "[1, 32, 116367/2458]", "GPS GPSAltitudeRef": "0", "GPS GPSAltitude": "20", "GPS GPSTimeStamp": "[11, 9, 5]", "GPS GPSMapDatum": "WGS-84", "GPS GPSDate": "2000:01:03", "Image GPSInfo": "252", "EXIF ExifVersion": "0230", "EXIF DateTimeOriginal": "2000:01:03 12:09:05", "EXIF DateTimeDigitized": "2000:01:03 12:09:05", "EXIF ComponentsConfiguration": "YCbCr", "EXIF FlashPixVersion": "0100", "EXIF ColorSpace": "Uncalibrated"}