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.
In 2012, Gmail's chat history showed a date of 12/31/69 for all chats saved on Feb 29, 2012. On the same day Microsoft's cloud computing solution Azure went down for 8 hours caused by a leap year bug.
Some digital systems have wrongly calculated which years are leap years. The best-known case occurred in Sony's PlayStation 3: The system treated 2010 as a leap year, so a non-existent date February 29, 2010 was shown on March 1, 2010, and caused program error.
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. This bug has been promoted into a requirement in the Ecma Office Open XML (OOXML) specification. From Section 3.17.41 of SpreadsheetML Reference Material, page 3305 of the OOXML specification, “Date Representation”:
For legacy reasons, an implementation using the 1900 date base system shall treat 1900 as though it was a leap year. [Note: That is, serial value 59 corresponds to February 28, and serial value 61 corresponds to March 1, the next day, allowing the (nonexistent) date February 29 to have the serial value 60. end note] A consequence of this is that for dates between January 1 and February 28, WEEKDAY shall return a value for the day immediately prior to the correct day, so that the (nonexistent) date February 29 has a day-of-the-week that immediately follows that of February 28, and immediately precedes that of March 1.