Leap year bug

From HandWiki

The leap year bug (also known as the leap year problem) is a problem for both digital (computer-related) and non-digital documentation and data storage situations which results from the wrong calculation of which years are leap years.

Type

There have been several occurrences of the leap year bug:

  • In 2012, Microsoft Azure was taken offline by the leap year bug on February 28, 2012. At 5:45 PM PST Windows Azure team became aware of an issue, apparently due to a time calculation that was incorrect for the leap year.
  • In 2012, Gmail's chat history showed a date of 12/31/69 for all chats saved on February 29, 2012.[citation needed]
  • Sony's PlayStation 3 incorrectly treated 2010 as a leap year, so the non-existent February 29, 2010 was shown on March 1, 2010, and caused a program error.[1]
  • At midnight on December 31, 2008, many[2] first generation Zune 30 models froze.[3][4] Microsoft stated that the problem was caused by the internal clock driver written by Freescale and the way the device handles a leap year. It automatically fixed itself 24 hours later, but an intermediate "fix" for those who did not wish to wait was to drain the device's battery and then recharge after 12 noon UTC on January 1, 2009.[5][6]
  • Microsoft Excel has, since its earliest versions, incorrectly considered 1900 to be a leap year, and therefore that February 29, 1900 comes between February 28 and March 1 of that year. The bug originated from Lotus 1-2-3, and was purposely implemented in Excel for the purpose of backward compatibility. Microsoft has written an article about this bug, explaining the reasons for treating 1900 as a leap year.[7] This bug has been promoted into a requirement in the Ecma Office Open XML (OOXML) specification.[8][9]

See also

  • Year 2100 problem

References