Misplaced Pages

Time formatting and storage bugs: Difference between revisions

Article snapshot taken from Wikipedia with creative commons attribution-sharealike license. Give it a read and then ask your questions in the chat. We can research this topic together.
Browse history interactively← Previous editContent deleted Content addedVisualWikitext
Revision as of 04:51, 18 November 2022 editPascal666 (talk | contribs)Extended confirmed users17,486 edits Years 4000 and 8000: Add more context and neutral phrasing← Previous edit Latest revision as of 16:29, 4 January 2025 edit undo83.43.233.44 (talk) Year 2025Tag: Visual edit 
(316 intermediate revisions by more than 100 users not shown)
Line 1: Line 1:
{{short description|Software errors affecting times and dates}} {{Short description|Class of software bugs}}
{{Use dmy dates|date=October 2022}} {{Use dmy dates|date=February 2023}}

In ], '''time formatting and storage bugs''' are a class of ]s that may cause ] calculation or display to be improperly handled. These are most commonly manifestations of ], but can also be the result of other issues. The most well-known consequence of bugs of this type is the ], but many other milestone dates or times exist that have caused or will cause problems depending on various programming deficiencies. In ], ] limitations and ] can cause errors in ] calculation or display. These are most commonly manifestations of ], but can also be the result of other issues. The best-known consequence of this type is the ], but many other milestone dates or times exist that have caused or will cause problems depending on various programming deficiencies.


== Year 1975 == == Year 1975 ==
On 5&nbsp;January 1975, the 12-bit field that had been used for dates in the ] operating system for DEC ] computers overflowed, in a bug known as "DATE75". The field value was calculated by taking the number of years since 1964, multiplying by 12, adding the number of months since January, multiplying by 31, and adding the number of days since the start of the month; putting {{nowrap|2<sup>12</sup> &minus; 1 {{=}} 4095}} into this gives 4&nbsp;January 1975, which is therefore the latest encodable date. The "DATE-75" patch pushed the last encodable date to 1&nbsp;February 2052, making the overflow date 2&nbsp;February 2052, by using 3 spare bits from other fields in the ]'s ], but this sometimes caused problems with software that used those bits for its own purposes. Some software may have supported using one additional bit for the date but had issues with additional bits, which could have resulted in some bugs on 9&nbsp;January 1986.<ref>{{Cite mailing list |last=Hoey |first=Dan |title=Software alert: DATE-86 |mailing-list=ARPANET-BBOARDS@MIT-MC.ARPA |date=11 December 1985 |publication-date=14 Dec 1985 <!-- "ReSent" from Arpanet-BBoards-Request@MIT-MC.ARPA --> |url=http://catless.ncl.ac.uk/Risks/4.45.html}} Reproduced in: {{cite journal |last=Austein |first=Rob |date=30 January 1987 <!-- date of submission --> |editor-last=Neumann |editor-first=Peter G. |title=DATE-86, or The Ghost of Tinkles Past |url=http://catless.ncl.ac.uk/Risks/4.45.html |journal=The RISKS Digest |publisher=Forum on Risks to the Public in Computers and Related Systems, ACM Committee on Computers and Public Policy |publication-date=2 February 1987 <!-- issue date of The RISKS Digest --> |volume=4 |issue=45 |access-date=29 December 2014}}</ref><ref>{{Cite web |last=Davison |first=Andrew |date=28 May 2021 <!-- PDF "Create Date" and "Modify Date", and HTTP "Last-Modified" --> |title=Jan. 4th : TOPS-10 Dating Woes: Jan. 4, 1975 |url=https://coe.psu.ac.th/ad/Y379/Jan/January_04.pdf |access-date=2024-10-11 |website=A Year of 379 Computer Days}}</ref><ref>{{Cite newsgroup |url=https://groups.google.com/g/alt.sys.pdp10/c/NygaiM35b_Q/m/bRKPDw9ndt8J |title=What was the TOPS-10 DATE75 fix? |last=Shoppa |first=Tim |date=November 7, 1998 |newsgroup=alt.sys.pdp10 |message-id=36444B15...@trailing-edge.com |access-date=2024-10-11 |via=Google Groups}}</ref><ref>{{Cite web |last=Werme |first=Ric |date=13 January 2021 |orig-date=last updated 29&nbsp;March 2024 |title=DATE75, PDP-10, TULIP, and C |department=Computer folklore |url=http://wermenh.com/folklore/dirlop.html |access-date=2024-10-11 |website=Werme Family Home Page}}</ref><ref name="csdates">{{Cite web|title=Critical and Significant Dates|url=http://people.cs.nycu.edu.tw/~tsaiwn/sisc/runtime_error_200_div_by_0/www.merlyn.demon.co.uk/critdate.htm|access-date=2024-02-12 |website=people.cs.nycu.edu.tw |language=en}}</ref>
On 4 January 1975, the 12-bit field that had been used for dates in the ] operating systems overflowed. There were numerous problems and crashes related to this bug while an alternative format was developed.<ref>{{cite journal|last=Austein|first=Rob|title=DATE-86, or The Ghost of Tinkles Past|url=http://catless.ncl.ac.uk/Risks/4.45.html|journal=The RISKS Digest|date=2 February 1987|volume=4|issue=45|publisher=ACM Committee on Computers and Public Policy|access-date=29 December 2014}}</ref>


== Year 1978 == == Year 1978 ==
The Digital Equipment Corporation ] operating system for the ] computer used only three bits for the year, representing the years 1970 to 1977.<ref>{{cite web|url=http://www.pdp8online.com/pdp8cgi/os8_html?act=dir;fn=linctape-images/os8l/ps-8-system-25.linc;sort=ext|title=Directory of linctape-images/os8l/ps-8-system-25.linc|quote=OS/8 can only store dates for an 8 year period...}}</ref> The Digital Equipment Corporation ] operating system for the ] computer used only three bits for the year, representing the years 1970 to 1977.<ref name="csdates" /><ref>{{cite web|url=http://www.pdp8online.com/pdp8cgi/os8_html?act=dir;fn=linctape-images/os8l/ps-8-system-25.linc;sort=ext |title=Directory of linctape-images/os8l/ps-8-system-25.linc |quote=OS/8 can only store dates for an 8 year period...}}</ref>

This was recognized when the later ] operating system was developed, and dates were recorded differently.<ref name=Jones.cs>{{cite web|url=http://homepage.cs.uiowa.edu/~jones/pdp8/faqs|title=The Digital Equipment Corporation PDP-8 : Frequently Asked Questions|quote=COS-310, DEC's commercial operating system for the PDP-8 ... file system is almost the same as OS/8, but dates are recorded differently}}</ref>


This was recognized when the ] operating system was developed, and dates were recorded differently.<ref name=Jones.cs>{{cite web|url=http://homepage.cs.uiowa.edu/~jones/pdp8/faqs|title=The Digital Equipment Corporation PDP-8 : Frequently Asked Questions|quote=COS-310, DEC's commercial operating system for the PDP-8 ... file system is almost the same as OS/8, but dates are recorded differently}}</ref>
== Year 1989 ==
Some mainframe programs were written to encode dates as the number of days since a 'zero date' of 1 January 1900, storing them as signed 16-bit binary integers. On 18 September 1989, these programs began to fail, the date being exactly 32,768 (2{{sup|15}}) days since the zero date. Values on and after this day do not fit into a signed 16-bit integer, but overflow and return negative values.{{citation needed|date=December 2021}}


== Year 1993 == == Year 1993 ==
Multiple ] games released for the ] started to ] when running on 18 September 1993. An issue in the Mac version of ] (Mac SCI) would cause the game to "lock-up" when attempting to handle a delay due to a problem involving an overflow. Mac SCI would attempt to use the date to determine how long a delay should last by getting the current time in seconds since 1 January 1904, the ], and dividing by 12 hours. The division was processed by the ] and would not occur if an overflow was detected because of the division, but the Mac SCI would continue on regardless as if the division had occurred, eventually resulting in a delay of one second being treated as a delay for 18 hours and so on. Sierra released a patch called MCDATE that resolved the problem for ].<ref name="Sierra">{{multiref| ]|}}</ref> Multiple ] games released for the ] started to ] when running on 18&nbsp;September 1993. An issue in the Mac version of ] (Mac SCI) would cause the game to "lock-up" when attempting to handle a delay due to a problem involving an overflow. Mac SCI would attempt to use the date to determine how long a delay should last by getting the current time in seconds since 1&nbsp;January 1904, the ], and dividing by 12&nbsp;hours. The division was processed by the ] and would not occur if an overflow was detected because of the division, but the Mac SCI would continue on regardless as if the division had occurred, eventually resulting in a delay of one second being treated as a delay for 18&nbsp;hours and so on. Sierra released a patch called MCDATE that resolved the problem for ].<ref name="Sierra">{{Cite magazine |url=https://archive.org/details/InterAction_Magazine_Vol._VI_Number_3_Holiday_1993_1993_Sierra_On-Line_US |title=News Notes |magazine=InterAction Magazine |volume=VI |issue=3 |date=1993 |page=12 |publisher=]}}</ref><ref>{{Cite web |title=Sierra's Macintosh Timebomb |url=https://www.benshoof.org/blog/sierras-macintosh-timebomb |access-date=2023-03-09 |website=www.benshoof.org}}</ref>


== Year 1997 == == Year 1997 ==
The ] clock, which is based on the number of 4-microsecond units that has occurred since 1 January 1980, rolled past 47 bits on 2 November 1997, rendering unpatched systems unusable.<ref>{{Cite web|url=http://jim.rees.org/apollo-archive/date-bug|title=Latest News on the Date Bug}}</ref> In ]'s ] operating system, absolute time was stored as a signed 48-bit integer representing the number of 4-microsecond units since 1&nbsp;January 1980. This value overflowed on 2&nbsp;November 1997, rendering unpatched systems unusable.<ref name="csdates" /><ref>{{Cite web|url=http://jim.rees.org/apollo-archive/date-bug|title=Latest News on the Date Bug}}</ref>


== Year 1999 == == Year 1999 ==
Line 26: Line 24:
{{main|GPS week number rollover}} {{main|GPS week number rollover}}
{{See also|GPS#Timekeeping}} {{See also|GPS#Timekeeping}}
GPS dates are expressed as a week number and a day-of-week number, with the week number transmitted as a ten-] value. This means that every 1,024 weeks (about 19.6 years) after Sunday 6 January 1980 (the GPS ]), the date resets again to that date; this happened for the first time at 23:59:47 on 21 August 1999,<ref name="tothenines">{{cite news|author=Janis L. Gogan|title=Applications To The Nines|url=http://www.informationweek.com/747/47uwjg.htm|work=]|date=9 August 1999|access-date=21 January 2008|archive-url=https://web.archive.org/web/20081003073858/http://www.informationweek.com/747/47uwjg.htm|archive-date=3 October 2008}}</ref> the second time at 23:59:42 ] on 6 April 2019, and will happen again on 20 November 2038.<ref name=cybergovau>{{cite web|title=GPS week roll over April 6th|url=https://www.cyber.gov.au/news/gps-rollover|website=www.cyber.gov.au|access-date=10 June 2019}}</ref> To address this concern, modernised GPS navigation messages use a 13-bit field, which only repeats every 8,192 weeks (157 years), and will not return to zero until near the year 2137.{{Citation needed|date=January 2022}} GPS dates are expressed as a week number and a day-of-week number, with the week number transmitted as a ten-] value. This means that every 1,024 weeks (about 19.6&nbsp;years) after Sunday 6&nbsp;January 1980, (the GPS ]), the date resets again to that date; this happened for the first time at 23:59:47 on 21&nbsp;August 1999,<ref name="tothenines">{{cite news|author=Janis L. Gogan|title=Applications to the Nines|url=http://www.informationweek.com/747/47uwjg.htm|work=]|date=9 August 1999|access-date=21 January 2008|archive-url=https://web.archive.org/web/20081003073858/http://www.informationweek.com/747/47uwjg.htm|archive-date=3 October 2008}}</ref> the second time at 23:59:42 ] on 6&nbsp;April 2019, and will happen again on 20&nbsp;November 2038.<ref name="cybergovau">{{cite web|title=GPS week roll over April 6th |url=https://www.cyber.gov.au/news/gps-rollover|website=cyber.gov.au|access-date=10 June 2019|archive-url=https://web.archive.org/web/20191020075611/https://www.cyber.gov.au/news/gps-rollover|archive-date=20 October 2019|url-status=dead}}</ref> To address this concern, modernised GPS navigation messages use a 13-bit field, which only repeats every 8,192&nbsp;weeks (157&nbsp;years), and will not return to zero until the year 2137.<ref name="csdates" /><ref>{{Cite web| title=GPS Week Number Rollover - April 2019| website=GPS.gov| access-date=25 February 2023| date=6 April 2019| url=https://www.gps.gov/support/user/rollover/ | publisher=National Coordination Office for Space-Based Positioning, Navigation, and Timing}}</ref>


=== 9/9/99 === === 9/9/99 ===
{{See also|Magic number (programming)|Magic string}} {{See also|Magic number (programming)|Magic string}}
In many programs or data sets, "9/9/99" was used as a ] to indicate either an unresolved date or as a terminator to indicate no further data was in the set. This raised issues upon the arrival of the actual date this represents, 9 September 1999.<ref name="tothenines"/> Many legacy programs or data sets used "9/9/99" as a ] to indicate either an unresolved date or as a terminator to indicate no further data was in the set. This caused many systems to crash upon the arrival of the actual date this represents, 9&nbsp;September 1999.<ref name="csdates" /><ref name="tothenines" />


==Year 2000== == Year 2000 ==
=== Two-digit year representations === === Two-digit year representations ===
{{main|Year 2000 problem}} {{main|Year 2000 problem}}
{{See also|Year 1900 problem}} {{See also|Year 1900 problem}}


The term year 2000 problem, or simply Y2K, refers to potential computer errors related to the formatting and storage of calendar data for dates in and after the year 2000. Many programs represented four-digit years with only the final two digits, making the year 2000 indistinguishable from 1900. Computer systems' inability to distinguish dates correctly had the potential to bring down worldwide infrastructures for computer reliant industries.
Follow-on problems caused by certain temporary fixes to the Y2K problem will crop up at various points in the 21st century. Some programs were made Y2K-compliant by continuing to use two digit years, but picking an arbitrary year prior to which those years are interpreted as 20''xx'', and after which are interpreted as 19''xx''.<ref>{{cite web|url=http://www.uic.edu/depts/accc/software/isodates/fixing.html|title=Identifying and Correcting Dates with Two-Digit Years|access-date=19 January 2010|author=Roger Deschner|date=21 December 2001|publisher=University of Illinois at Chicago}} See "Example 1: 100 Year Fixed Window, 1973 to 2072"</ref>


For applications required to calculate the birth year (or another past year), such an algorithm has long been used to overcome the ], but it has failed to recognise ].
For example, a program may have been changed so that it treats two-digit year values 00–68 as referring to 2000 through 2068, and values 69–99 as referring to 1969 through 1999.<ref>, ] Base Specifications Issue 6. IEEE Std 1003.1, 2004 Edition</ref> Such a program will not be able to correctly deal with years beyond 2068.

For applications required to calculate the birth year (or another past year), such an algorithm has long been used to overcome the ], but it has failed to recognise ].


== Year 2001 == == Year 2001 ==
Systems that used a string of nine digits to record the time as seconds since the ] had issues reporting times beyond the one-billionth second after the epoch on 9 September 2001 at 01:46:40 (the "billenium"). Problems were not widespread.<ref>{{cite magazine|last=Manjoo|first=Farhad|title=Unix Tick Tocks to a Billion|url=https://www.wired.com/2001/09/unix-tick-tocks-to-a-billion/|magazine=Wired|access-date=29 March 2022}}</ref> Systems that used a string of nine digits to record the time as seconds since the ] had issues reporting times beyond the one-billionth second after the epoch on 9&nbsp;September 2001 at 01:46:40 (the "billennium"). Problems were not widespread.<ref name="csdates" /><ref>{{cite magazine|last=Manjoo|first=Farhad|title=Unix Tick Tocks to a Billion|url=https://www.wired.com/2001/09/unix-tick-tocks-to-a-billion/|magazine=Wired|access-date=29 March 2022}}</ref>


== Year 2007 == == Year 2007 ==
Sierra Entertainment games for the Classic Mac OS that were patched with the MCDATE program or released afterwards with the patch built in would begin to freeze on 28 May 2007. As with the ] program, this was due to an issue in the Mac SCI when attempting to use the date to determine how long a delay should last. Programs with the MCDATE patch freeze because the Mac SCI takes the current number of seconds since the ] of 1 January 1904, subtracts 432,000,000 seconds from that, and then divides by 12 hours through the Motorola 68000, to then determine how long delays should last. On 28 May 2007, the Motorola 68000 again does not divide due to overflow protection, which the Mac SCI ignores.<ref name="Sierra"/> Sierra Entertainment games for the Classic Mac OS that were patched with the MCDATE program or released afterwards with the patch built in would begin to freeze on 28&nbsp;May 2007. As with the ] problem, this was due to an issue in the Mac SCI when attempting to use the date to determine how long a delay should last. Programs with the MCDATE patch freeze because the Mac SCI takes the current number of seconds since the ] of 1&nbsp;January 1904, subtracts 432,000,000&nbsp;seconds from that, and then divides by 12&nbsp;hours through the Motorola 68000, to then determine how long delays should last. On 28&nbsp;May 2007, the Motorola 68000 again does not divide due to overflow protection, which the Mac SCI ignores.<ref name="Sierra" />


== Year 2010 == == Year 2010 ==
Some systems had problems once the year rolled over to 2010. This was dubbed by some in the media as the "Y2K+10" or "Y2.01k" problem.<ref>{{cite web|url=http://www.crn.com.au/News/163864,bank-of-queensland-hit-by-y201k-glitch.aspx|title=Bank of Queensland hit by "Y2.01k" glitch|date=4 January 2010}}</ref> Some systems had problems once the year rolled over to 2010. This was dubbed by some in the media as the "Y2K+10" or "Y2.01k" problem.<ref>{{cite web|url=https://www.crn.com.au/news/bank-of-queensland-hit-by-y201k-glitch-163864|title=Bank of Queensland hit by "Y2.01k" glitch|date=4 January 2010|access-date=25 February 2023}}</ref>


The main source of problems was confusion between hexadecimal number encoding and ] encodings of numbers. The numbers 0 through 9 are encoded in both hexadecimal and BCD as 00{{sub|16}} through 09{{sub|16}}. But the decimal number 10 is encoded in hexadecimal as 0A{{sub|16}} and in BCD as 10{{sub|16}}. Thus a BCD 10{{sub|16}} interpreted as a hexadecimal encoding erroneously represents the decimal number 16. The main source of problems was confusion between hexadecimal number encoding and ] encodings of numbers. The numbers 0 through 9 are encoded in both hexadecimal and BCD as 00{{sub|16}} through 09{{sub|16}}. But the decimal number 10 is encoded in hexadecimal as 0A{{sub|16}} and in BCD as 10{{sub|16}}. Thus a BCD 10{{sub|16}} interpreted as a hexadecimal encoding erroneously represents the decimal number 16.


For example, the ] protocol uses BCD encoding for dates, so some mobile phone software incorrectly reported dates of messages as 2016 instead of 2010. ] was the first software reported to have been affected by this glitch; in some cases WM6 changed the date of any incoming SMS message sent after 1 January 2010 from the year 2010 to 2016.<ref name=wm6>{{cite web|url= http://news.cnet.com/8301-13860_3-10425455-56.html?tag=newsLatestHeadlinesArea.0#addcomm|title=Windows Mobile glitch dates 2010 texts 2016|date=5 January 2010}}</ref><ref name="cellphone2010">{{cite web|url=http://www.techradar.com/news/world-of-tech/windows-mobile-phones-suffer-y2k-10-bug-661062|title=Windows Mobile phones suffer Y2K+10 bug|date=4 January 2010|access-date=3 July 2013|archive-url=https://web.archive.org/web/20131023061135/http://www.techradar.com/news/world-of-tech/windows-mobile-phones-suffer-y2k-10-bug-661062|archive-date=23 October 2013|url-status=dead}}</ref> For example, the ] protocol uses BCD encoding for dates, so some mobile phone software incorrectly reported dates of messages as 2016 instead of 2010. ] was the first software reported to have been affected by this glitch; in some cases WM6 changed the date of any incoming SMS message sent after 1&nbsp;January 2010, from the year 2010 to 2016.<ref name="csdates" /><ref name="wm6">{{cite web|url=https://www.cnet.com/culture/windows-mobile-glitch-dates-2010-texts-2016/|title=Windows Mobile glitch dates 2010 texts 2016|first=Ina|last=Fried|date=5 January 2010|website=]|access-date=24 February 2023}}</ref><ref name="cellphone2010">{{cite web|url=http://www.techradar.com/news/world-of-tech/windows-mobile-phones-suffer-y2k-10-bug-661062|title=Windows Mobile phones suffer Y2K+10 bug|date=4 January 2010|access-date=3 July 2013|archive-url=https://web.archive.org/web/20131023061135/http://www.techradar.com/news/world-of-tech/windows-mobile-phones-suffer-y2k-10-bug-661062|archive-date=23 October 2013|url-status=dead}}</ref>


Other systems affected include ] terminals,<ref>{{cite web|url=http://www.itwire.com/content/view/30308/53/|title=Bank of Queensland vs Y2K – an update|date=4 January 2010|access-date=3 July 2013|archive-url=https://web.archive.org/web/20100108210918/http://www.itwire.com/content/view/30308/53/|archive-date=8 January 2010|url-status=dead}}</ref> and the ] (except the Slim model).<ref name="PS3-1">{{Cite web|url=https://gizmodo.com/error-8001050f-takes-down-playstation-network-5482365|title=Error: 8001050F Takes Down PlayStation Network|website=Gizmodo|first=Jack|last=Loftus|date=28 February 2010}}</ref> Other systems affected include ] terminals,<ref>{{cite web|url=http://www.itwire.com/content/view/30308/53/|title=Bank of Queensland vs Y2K – an update|date=4 January 2010|access-date=3 July 2013|archive-url=https://web.archive.org/web/20100108210918/http://www.itwire.com/content/view/30308/53/|archive-date=8 January 2010|url-status=dead}}</ref> and the ] (except the Slim model).<ref name="PS3-1">{{Cite web|url=https://gizmodo.com/error-8001050f-takes-down-playstation-network-5482365|title=Error: 8001050F Takes Down PlayStation Network|website=Gizmodo|first=Jack|last=Loftus|date=28 February 2010}}</ref>


Sony's ] incorrectly treated 2010 as a leap year, so the non-existent 29 February 2010 was shown on 1 March 2010 and caused a ].<ref>{{Cite web |last=Metrowebukmetro |date=2010-03-02 |title=Sony fixes PS3 'leap year' bug |url=https://metro.co.uk/2010/03/02/sony-fixes-ps3-leap-year-bug-138471/ |access-date=2022-10-25 |website=Metro |language=en}}</ref> Sony's ] incorrectly treated 2010 as a ], so the non-existent 29&nbsp;February 2010, was shown on 1&nbsp;March 2010, causing a ].<ref name="csdates" /><ref>{{Cite web |author=Metrowebukmetro |date=2 March 2010 |title=Sony fixes PS3 'leap year' bug |url=https://metro.co.uk/2010/03/02/sony-fixes-ps3-leap-year-bug-138471/ |access-date=25 October 2022 |website=Metro |language=en}}</ref>


The most important such glitch occurred in Germany, where upwards of 20 million bank cards became unusable, and with Citibank Belgium, whose digipass customer identification chips stopped working.<ref>{{cite web|url=http://www.rtlinfo.be/info/monde/europe/297916/bug-de-l-an-2010-en-allemagne-plus-de-20-millions-de-cartes-bancaires-inutilisables|title=2010 Bug in Germany|date=6 January 2010}}</ref> The most important such glitch occurred in Germany, where upwards of 20 million bank cards became unusable, and with Citibank Belgium, whose digipass customer identification chips stopped working.<ref>{{cite web|url=https://www.rtl.be/art/info/monde/international/bug-de-l-an-2010-en-allemagne-plus-de-20-millions-de-cartes-bancaires-inutilisables-145867.aspx|title=Bug de l'an 2010 en Allemagne: plus de 20 millions de cartes bancaires inutilisables|trans-title=2010 Bug in Germany: more than 20 million unusable bank cards|language=fr-be|date=5 January 2010|website=RTL Belgium|access-date=25 February 2023}}</ref>


== Year 2011 == == Year 2011 ==
{{main|Year 2011 problem}} {{main|Year 2011 problem}}
] officially uses the ], which considers the ] year 1912 to be its year 1. Thus, the Gregorian year 2011 is the ROC year 100, its first 3-digit year.<ref>{{Cite web|url=http://pinyin.info/news/2006/taiwans-y1c-problem/|title=Taiwan's Y1C problem|website=Pinyin News|date=2 January 2006}}</ref> ] officially uses the ], which considers the ] year 1912 to be its year 1. Thus, the Gregorian year 2011 is the ROC year 100, its first 3-digit year.<ref name="csdates" /><ref>{{Cite web|url=http://pinyin.info/news/2006/taiwans-y1c-problem/|title=Taiwan's Y1C problem|website=Pinyin News|date=2 January 2006}}</ref> This causes the year to appear to be 1911 (Year 0) if 2-digit representations are used.


== Year 2013 == == Year 2013 ==
The uncrewed ] space probe lost communication with Earth on 11 August 2013 because of a time tagging problem; the date was stored as an unsigned 32-bit integer counting the number of tenth-seconds since January 1, 2000.<ref>{{cite web|url=http://www.jpl.nasa.gov/news/news.php?release=2013-287|publisher=Jet Propulsion Laboratory|date=20 September 2013|title= NASA's Deep Space Comet Hunter Mission Comes to an End|archive-url=https://web.archive.org/web/20131014090812/http://www.jpl.nasa.gov/news/news.php?release=2013-287|accessdate=9 July 2022|archive-date=14 October 2013|url-status=live}}</ref> The ] space probe lost communication with Earth on 11&nbsp;August 2013, because of a time-tagging problem; the date was stored as an unsigned 32-bit integer counting the number of tenth-seconds since 1&nbsp;January 2000.<ref>{{cite web|url=http://www.jpl.nasa.gov/news/news.php?release=2013-287|publisher=Jet Propulsion Laboratory|date=20 September 2013|title= NASA's Deep Space Comet Hunter Mission Comes to an End|archive-url=https://web.archive.org/web/20131014090812/http://www.jpl.nasa.gov/news/news.php?release=2013-287|access-date=9 July 2022|archive-date=14 October 2013|url-status=live}}</ref>

== Year 2015 ==
Older ] mobile phones with ] chipsets, such as Samsung SGH-C170, were unable to change dates beyond 31 December 2014, and before 1 January 1998.{{citation needed|date=October 2021}}


== Year 2019 == == Year 2019 ==
=== Second GPS rollover === === Second GPS rollover ===
In 2019, the ] occurred. ] computerized telescope with GPS like the LX200GPS could no longer find their location and thus could not align themselves or locate stellar objects. Meade released a new firmware 4.2k with a fix but which also introduced many new bugs. 4.2l (little L, often confused with I) was released to fix that, but had more inexplicable changes. A 3rd party, StarPatch, released a hacked version of firmware 4.2g for free to fix the issues.
In 2019, the ] occurred.


=== Japanese calendar transition === === Japanese calendar transition ===
{{main|Japanese calendar era bug}} {{main|Japanese calendar era bug}}
On 30 April 2019, Emperor ] of Japan ] in favor of his son ]. As years in Japan are traditionally referred to by ]s that correspond to the reign of each emperor, this resulted in a new era name, {{nihongo|]|令和}}, following Naruhito's accession to the throne the following day. Because the previous emperor, ], died 7 January 1989 and Akihito's reign mostly corresponded with the rise in the use of computers, most software had not been tested to ensure correct behavior on an era change, while testing was further complicated by the fact that the new era name was not revealed until 1 April 2019. Therefore, errors were expected from software that did not anticipate a new era. On 30&nbsp;April 2019, Emperor ] of Japan ] in favor of his son ]. As years in Japan are traditionally referred to by ]s that correspond to the reign of each emperor, this resulted in a new era name, {{nihongo|]|令和}}, following Naruhito's accession to the throne the following day. Because the previous emperor, ], died 7&nbsp;January 1989, and Akihito's reign mostly corresponded with the rise in the use of computers, most software had not been tested to ensure correct behavior on an era change, while testing was further complicated by the fact that the new era name was not revealed until 1&nbsp;April 2019. Therefore, errors were expected from software that did not anticipate a new era.


== Year 2020 == == Year 2020 ==
The video games '']'' and '']'' would both ] on 1 January 2020, when the year rolled over. The glitches could only be circumvented by resetting the year back to 2019 until a patch was released.<ref>{{Cite web|url=https://segmentnext.com/2020/01/01/wwe-2k20-refuses-2020/|title=WWE 2K20 Refuses To Run In 2020|last=Mansoor|first=Saqib|date=1 January 2020|website=SegmentNext|access-date=1 January 2020}}</ref><ref>{{Cite web|date=1 January 2020|title=Star Wars Jedi: Fallen Order and WWE 2K20 are not launching due to a "2020" bug |url=https://www.dsogaming.com/news/star-wars-jedi-fallen-order-wwe-2k20-and-other-games-are-not-launching-due-to-a-denuvo-2020-bug/|access-date=19 November 2020|website=DSOGaming}}</ref> Additionally, ] would fail to generate specific reports starting in 2020.<ref>{{Cite web|title=sql - ODBC Connection / Crystal Reports|url=https://stackoverflow.com/questions/59580722/odbc-connection-crystal-reports|access-date=19 November 2020|website=Stack Overflow}}</ref> The video games '']'' and '']'' both ] on 1&nbsp;January 2020, when the year rolled over. The glitches could only be circumvented by resetting the year back to 2019 until a patch was released.<ref>{{Cite web|url=https://segmentnext.com/2020/01/01/wwe-2k20-refuses-2020/|title=WWE 2K20 Refuses To Run In 2020|last=Mansoor|first=Saqib|date=1 January 2020|website=SegmentNext|access-date=1 January 2020}}</ref><ref>{{Cite web|date=1 January 2020|title=Star Wars Jedi: Fallen Order and WWE 2K20 are not launching due to a "2020" bug |url=https://www.dsogaming.com/news/star-wars-jedi-fallen-order-wwe-2k20-and-other-games-are-not-launching-due-to-a-denuvo-2020-bug/|access-date=19 November 2020|website=DSOGaming}}</ref> Additionally, ] would fail to generate specific reports starting in 2020.<ref>{{Cite web|title=sql ODBC Connection / Crystal Reports|url=https://stackoverflow.com/questions/59580722/odbc-connection-crystal-reports|access-date=19 November 2020|website=Stack Overflow}}</ref>


] parking meters in New York City and other locations were unable to accept credit cards as a form of payment starting in 2020. A workaround was implemented, but required each meter to be individually updated. In New York, the meters were not expected to be fixed until 9 January.<ref>{{Cite web|date=2 January 2020|title=Parking Meters Across NYC Not Accepting Credit Cards, Were Never Programmed To Work In 2020|url=https://newyork.cbslocal.com/2020/01/02/parking-meters-nyc-credit-cards/|access-date=19 November 2020}}</ref><ref>{{Cite web|url=https://gothamist.com/news/y2k20-parking-meter-software-glitch-causes-citywide-snafu|title=Y2K20 Parking Meter Software Glitch Causes Citywide SNAFU - Gothamist|access-date=4 January 2020|archive-url=https://web.archive.org/web/20200104210355/https://gothamist.com/news/y2k20-parking-meter-software-glitch-causes-citywide-snafu|archive-date=4 January 2020|url-status=dead}}</ref> ] parking meters in New York City and other locations were unable to accept credit cards as a form of payment starting in 2020. A workaround was implemented, but required each meter to be individually updated. In New York, the meters were not expected to be fixed until 9 January.<ref>{{Cite news|date=2 January 2020|title=Parking Meters Across NYC Not Accepting Credit Cards, Were Never Programmed To Work In 2020|url=https://newyork.cbslocal.com/2020/01/02/parking-meters-nyc-credit-cards/|access-date=19 November 2020}}</ref><ref>{{Cite web|url=https://gothamist.com/news/y2k20-parking-meter-software-glitch-causes-citywide-snafu|title=Y2K20 Parking Meter Software Glitch Causes Citywide SNAFU Gothamist|access-date=4 January 2020|archive-url=https://web.archive.org/web/20200104210355/https://gothamist.com/news/y2k20-parking-meter-software-glitch-causes-citywide-snafu|archive-date=4 January 2020|url-status=dead}}</ref>


In Poland, 5,000 ]s stopped printing the date out properly.<ref>{{Cite web|url=https://businessinsider.com.pl/finanse/handel/awaria-kas-fiskalnych-novitusa-firmy-licza-strarty/nyclnv2|title=Wielka awaria drukarek fiskalnych. Producent naprawia urządzenia, firmy liczą straty|last=Pallus|first=Patryk|date=3 January 2020|website=Business Insider|language=pl|access-date=4 January 2020}}</ref> In Poland, 5,000 ]s stopped printing the date out properly.<ref>{{Cite web|url=https://businessinsider.com.pl/finanse/handel/awaria-kas-fiskalnych-novitusa-firmy-licza-strarty/nyclnv2|title=Wielka awaria drukarek fiskalnych. Producent naprawia urządzenia, firmy liczą straty|last=Pallus|first=Patryk|date=3 January 2020|website=Business Insider|language=pl|access-date=4 January 2020}}</ref>


] sport smart watches displayed an error in computing week days, that was presented with a +2 step (e.g. FRI rather than WED, SAT rather than THU). For Suunto Spartan model watches, the bug was fixed with firmware release 2.8.32.<ref>{{Cite web|url=https://www.suunto.com/en-gb/Support/Software-updates/Release-notes/suunto-spartan-software-updates/|title = Suunto Spartan Software updates}}</ref> ] sport smart watches displayed an error in computing weekdays that were presented with a +2 step (e.g. FRI rather than WED, SAT rather than THU). For Suunto Spartan model watches, the bug was fixed with firmware release 2.8.32.<ref>{{Cite web|url=https://www.suunto.com/en-gb/Support/Software-updates/Release-notes/suunto-spartan-software-updates/|title = Suunto Spartan Software updates}}</ref>


=== Classic Mac OS === === Classic Mac OS ===
The control panel in Classic Mac OS versions 6, 7, and 8 only allows the date to be set as high as 31 December 2019, although the system is able to continue to advance time beyond that date.<ref>{{cite web|title=Technical Note TN1049 Approaching the Millennium: The Mac and the Year 2000|url=http://www.fenestrated.net/~macman/mirrors/Apple%20Technotes%20(As%20of%202002)/tn/tn1049.html|access-date=20 January 2020|archive-date=13 November 2014|archive-url=https://web.archive.org/web/20141113171013/http://www.fenestrated.net/~macman/mirrors/Apple%20Technotes%20(As%20of%202002)/tn/tn1049.html|url-status=dead }}</ref><ref>{{cite web|title=Vintage Mac 2020 fixes|url=http://www.mactcp.net/macos2020.html|access-date=21 January 2020}}</ref> The control panel in Classic Mac OS versions 6, 7, and 8 only allows the date to be set as high as 31&nbsp;December 2019, although the system is able to continue to advance time beyond that date.<ref name="csdates" /><ref>{{cite web|title=Technical Note TN1049 Approaching the Millennium: The Mac and the Year 2000|url=http://www.fenestrated.net/~macman/mirrors/Apple%20Technotes%20(As%20of%202002)/tn/tn1049.html|access-date=20 January 2020|archive-date=13 November 2014|archive-url=https://web.archive.org/web/20141113171013/http://www.fenestrated.net/~macman/mirrors/Apple%20Technotes%20(As%20of%202002)/tn/tn1049.html|url-status=dead }}</ref><ref>{{cite web|title=Vintage Mac 2020 fixes|url=http://www.mactcp.net/macos2020.html|access-date=21 January 2020}}</ref>

=== Microsoft Schedule+ ===
The first version of ] as bundled with version 3.0 of the Microsoft Mail email client will refuse to work with years greater than 2020 or beyond, due to the fact that the program was designed to operate within a 100-year time window ranging from 1920 to 2019. As a result, the date can only be set as high as 31&nbsp;December 2019.<ref>{{Cite web |title=Q192201: XCLN: Schedule + 1.0 Will Not Run After 12/31/2019 |url=http://jeffpar.github.io/kbarchive/kb/192/Q192201/ |access-date=2022-07-06 |website=KnowledgeBase Archive |language=en-US}}</ref>


== Year 2021 == == Year 2021 ==
Samsung users reported that phones running on the latest ] or ] lost access to the battery and charging statistics starting in 2021. Affected devices would not report usage statistics, thus leaving those sections blank.<ref> PhoneArena</ref><ref></nowiki> Samsung One UI 3.0 (Android 11) update bugs & issues tracker] PiunikaWeb</ref> Older Sony Bravia models now report invalid data when trying to set EPG reminders.{{citation needed|date=October 2021}} Samsung users reported that phones running on the latest ] or ] lost access to the battery and charging statistics starting in 2021. Affected devices would not report usage statistics, thus leaving those sections blank.<ref>{{Cite web |last=Jeong |first=Eugene |title=Users report an interesting glitch in Samsung's One UI 3.0, but it has an easy fix |url=https://www.phonearena.com/news/samsung-battey-stats-missing-on-one-ui-3_id129282 |access-date=2023-03-09 |website=Phone Arena |date=13 January 2021 |language=en-US}}</ref><ref>{{Cite web |last=Bhardwaj |first=Deveshwar |date=2021-05-21 |title=Samsung One UI 3.0/3.1 (Android 11) update bug tracker |url=https://piunikaweb.com/2021/05/21/samsung-one-ui-3-0-android-11-update-bugs-issues-tracker/ |access-date=2023-03-09 |website=PiunikaWeb |language=en-US}}</ref>


== Year 2022 == == Year 2022 ==
Dates that are stored in the format yymmddHHMM converted to a signed 32-bit integer overflowed on 1 January 2022, as 2{{sup|31}}=2147483648. Notably affected was the malware-scanning component update numbers of ], which appear to be used for a mathematical check to determine the latest update.<ref>{{cite web|url=https://borncity.com/win/2022/01/01/exchange-fip-fs-scan-engine-failed-to-load-cant-convert-2201010001-to-long-1-1-2022/|first=Günter|last=Born|website=Born's Tech and Windows World|title=Exchange Year 2022 Problem: FIP-FS Scan Engine failed to load – Can't Convert "2201010001" to long (2022/01/01 00:00 UTC)|date=1 January 2022 | access-date = 1 January 2022}}</ref><ref>{{Cite web|url=https://news.sky.com/story/remember-the-y2k-bug-microsoft-confirms-new-y2k22-issue-12507401|title=Remember the Y2K bug? Microsoft confirms new Y2K22 issue|website=Sky News|first=Alexander|last=Martin|date=2 January 2022}}</ref> Dates that are stored in the format yymmddHHMM converted to a signed 32-bit integer overflowed on 1&nbsp;January 2022, since {{nowrap|2{{sup|31}} {{=}} 2147483648}}. Notably affected was the malware-scanning component update numbers of ], which appear to be used for a mathematical check to determine the latest update.<ref>{{cite web|url=https://borncity.com/win/2022/01/01/exchange-fip-fs-scan-engine-failed-to-load-cant-convert-2201010001-to-long-1-1-2022/|first=Günter|last=Born|website=Born's Tech and Windows World|title=Exchange Year 2022 Problem: FIP-FS Scan Engine failed to load – Can't Convert "2201010001" to long (2022/01/01 00:00 UTC)|date=1 January 2022 | access-date=1 January 2022}}</ref><ref>{{Cite web|url=https://news.sky.com/story/remember-the-y2k-bug-microsoft-confirms-new-y2k22-issue-12507401|title=Remember the Y2K bug? Microsoft confirms new Y2K22 issue|website=Sky News|first=Alexander|last=Martin|date=2 January 2022}}</ref>


Honda and Acura cars manufactured between 2004 and 2012 containing GPS navigation systems incorrectly displayed the year as 2002. This problem was due to an overflow on the GPS epoch. Honda confirmed that the issue would resolve itself in September 2022.<ref>{{Cite web|title=Honda Clocks Are Stuck 20 Years In The Past And There Isn't A Fix|url=https://jalopnik.com/honda-clocks-are-stuck-20-years-in-the-past-and-this-mi-1848306970|access-date=8 January 2022|website=Jalopnik|date=6 January 2022}}</ref><ref>{{Cite web|title=Shoddy coding has some Honda cars stuck in the year 2002|url=https://www.engadget.com/honda-2002-gps-bug-190248626.html|access-date=8 January 2022|website=Engadget}}</ref>{{update inline|reason=Has it resolved itself?|date=October 2022}} ] and ] cars manufactured between 2004 and 2012 containing ] systems incorrectly displayed the year as 2002. This problem was due to an overflow on the GPS epoch.<ref>{{Cite web|title=Honda Clocks Are Stuck 20 Years in the Past And There Isn't A Fix|url=https://jalopnik.com/honda-clocks-are-stuck-20-years-in-the-past-and-this-mi-1848306970|access-date=8 January 2022|website=Jalopnik|date=6 January 2022}}</ref><ref>{{Cite web|title=Shoddy coding has some Honda cars stuck in the year 2002|url=https://www.engadget.com/honda-2002-gps-bug-190248626.html|access-date=8 January 2022|website=Engadget|date=7 January 2022 }}</ref> The issue was resolved on August 17, 2022.<ref>{{Cite web |last=Acoba |first=Paulo |date=August 17, 2022 |title=Honda & Acura owners with clock problems report, as of August 17, their time is self-correcting but many are still stuck with the wrong date |url=https://tiremeetsroad.com/2022/08/17/honda-acura-owners-clock-problems-are-reporting-as-of-august-17-time-is-self-correcting-many-still-stuck-with-wrong-date/ |url-status=live |archive-url=https://web.archive.org/web/20230530080645/https://tiremeetsroad.com/2022/08/17/honda-acura-owners-clock-problems-are-reporting-as-of-august-17-time-is-self-correcting-many-still-stuck-with-wrong-date/ |archive-date=May 30, 2023}}</ref>

== Year 2024 ==
Payment card readers at petrol pumps in New Zealand were ] and were unable to properly dispense gasoline.<ref> Reuters</ref>

Video games '']'' and '']'' also suffered issues related to the leap year, with the former crashing when trying to load the game and the latter claiming that the save data was corrupted. Both games had to be set to the following day of March 1, 2024 to properly work.<ref>{{Cite web |date=2024-02-29 |title=Final Fantasy Game Broken Due To Leap Day |url=https://kotaku.com/final-fantasy-theatrhythm-broken-wrc-leap-day-bug-ps4-1851298039 |access-date=2024-10-10 |website=Kotaku |language=en}}</ref><ref>{{Cite web |last=Yin-Poole |first=Wesley |date=2024-02-29 |title=Theatrhythm Final Fantasy on Nintendo Switch Doesn't Work Today, Feb. 29, Seemingly Because It's a Leap Year |url=https://me.ign.com/en/nintendo-switch/218611/news/theatrhythm-final-fantasy-on-nintendo-switch-doesnt-work-today-feb-29-seemingly-because-its-a-leap-y |access-date=2024-10-10 |website=IGN Middle East |language=en-ae}}</ref><ref>{{Cite web |last=Dinsdale |first=Ryan |date=2024-02-29 |title=EA Sports WRC Crashing on Start-Up Today, Feb. 29, Because 2024's a Leap Year |url=https://me.ign.com/en/ps5/218621/news/ea-sports-wrc-crashing-on-start-up-today-feb-29-because-2024s-a-leap-year |access-date=2024-10-10 |website=IGN Middle East |language=en-ae}}</ref>

In December 2024, a 30 year old bug was found in all versions of ]. When the server is started on or after December 13 2024, an overflow will prevent the mail router to load its configuration, and so no mail is delivered. Patches were released on the next day for all supported versions.<ref>{{Cite web |title=CRITICAL ALERT: Mail not routing after Domino restarts beginning December 13, 2024 - Customer Support |url=https://support.hcl-software.com/csm?id=kb_article&sysparm_article=KB0118192 |access-date=2024-12-19 |website=support.hcl-software.com}}</ref>


== Year 2025 == == Year 2025 ==
In Japan, some older computer systems using the Japanese calendar that have not been updated still count years according to the ]. The year 2025 corresponds in those systems to Shōwa 100, which can cause problems if the software assumes two digits for the year.<ref>{{cite web|title=Big tech warns of 'Japan's millennium bug' ahead of Akihito's abdication|website=]|date=25 July 2018|url=https://www.theguardian.com/technology/2018/jul/25/big-tech-warns-japan-millennium-bug-y2k-emperor-akihito-abdication}}</ref> In Japan, some older computer systems using the Japanese calendar that have not been updated still count years according to the ]. The year 2025 corresponds in those systems to Shōwa 100, which can cause problems if the software assumes two digits for the year.<ref>{{cite web |title=Big tech warns of 'Japan's millennium bug' ahead of Akihito's abdication|website=]|date=25 July 2018 |url=https://www.theguardian.com/technology/2018/jul/25/big-tech-warns-japan-millennium-bug-y2k-emperor-akihito-abdication}}</ref>

In Spain, all ] class trains stopped operating on January 1, 2025 due to a date handling bug in the battery charging module, causing delays and cancellations as passengers were relocated in other rolling stock.<ref>{{cite news |last1=AGENCIAS |first1=RTVE es / |title=Los trenes Avril que unen Madrid con Galicia y Asturias, parados por un fallo informático |url=https://www.rtve.es/noticias/20250101/renfe-avril-talgo-madrid-galicia-asturias-incidencia-fallo-informatico/16392092.shtml |access-date=1 January 2025 |work=RTVE.es |date=1 January 2025 |language=es}}</ref><ref>{{cite news |title=Una avería en los cargadores de las baterías de los trenes Avril deja inoperativas todas las unidades |url=https://www.lavozdegalicia.es/noticia/galicia/2025/01/01/averia-informatica-afecta-circulacion-trenes-avril/00031735729880886584360.htm |access-date=1 January 2025 |work=La Voz de Galicia |date=1 January 2025 |language=es}}</ref> A bugfix was deployed by the next day, recovering regular service.<ref>{{Cite news |date=2 January 2025 |title=Los trenes Avril recuperan su normal funcionamiento tras solucionar el problema informático de los cargadores de baterías |url=https://www.talgo.com/es/los-trenes-avril-recuperan-su-normal-funcionamiento-tras-solucionar-el-problema-informatico-de-los-cargadores-de-baterias |access-date=4 January 2025 |work=] press release |language=es}}</ref>


== Year 2028 == == Year 2028 ==
Some systems store their year as a single-byte offset from 1900, which gives a range of 255 (8 bits) and allows dates up to 2155 to be safely represented. Unfortunately, not all systems use an ] byte: some have been mistakenly coded with a signed byte which only allows a range of 127 years, meaning that the date field in the software will be incorrect after 2027 and can cause unpredictable behaviour. Several pieces of optical disc software that operates using the ] format are affected by this.<ref>{{Cite web|url=http://rachelbythebay.com/w/2021/11/05/sevenbits/|title=Years since 1900 + seven bits = breakage in 2028|website=rachelbythebay.com}}</ref> Some systems store their year as a single-byte offset from 1900, which gives a range of 255 (8 bits) and allows dates up to 2155 to be safely represented. However, not all systems use an ] byte: some have been mistakenly coded with a signed byte which only allows a range of 127&nbsp;years, meaning that the date field in the software will be incorrect after 2027 and can cause unpredictable behaviour. Several pieces of optical-disc software that operate using the ] format are affected by this.<ref>{{Cite web |url=http://rachelbythebay.com/w/2021/11/05/sevenbits/|title=Years since 1900 + seven bits = breakage in 2028|website=rachelbythebay.com}}</ref>


During the late 1970s, on Data General Nova and Eclipse systems, the World Computer Corporation (doing credit union applications) created a date format with a 16-bit date field for 128 years (7 bits note 1900+128=2028), 12 months (4 bits) and 31 days (5 bits). This allowed dates to be directly comparable using unsigned functions. Some systems, including ], still use this format, although a patch has been developed by outside consultants.<ref>{{Cite web|url=https://www.beechglen.com/2027-patches-release-2017-12-12/|title=MPE/iX Release 7.5 Patch Revision 2028 – Beechglen Development Inc.}}</ref> During the late 1970s, on Data General Nova and Eclipse systems, the World Computer Corporation (doing credit union applications) created a date format with a 16-bit date field, which used seven bits for the year, four bits for the month, and five bits for the day. This allowed dates to be directly comparable using unsigned functions. Some systems, including ], still use this format, although a patch has been developed by outside consultants.<ref>{{Cite web|url=https://www.beechglen.com/2027-patches-release-2017-12-12/|title=MPE/iX Release 7.5 Patch Revision 2028 – Beechglen Development Inc.}}</ref>

== Year 2031 ==
Some systems, like ]'s ], only go up to 31 December 2030.{{Citation needed|date=November 2020}}


== Year 2032 == == Year 2032 ==
] uses both ] integers with the 1970 ], as well as unsigned integers with the 1904 epoch, for different system functions,<ref>{{cite web|title=Palm OS® Protein C/C++ Compiler Language & Library Reference|url=http://apitechwriter.com/Samples/PalmSource/PalmOS_API_Compiler_Ref.pdf|access-date=12 October 2019|ref=Page 232}}</ref> such as for system clock, and file dates (see ]). While this should result in Palm OS being susceptible to the ], Palm OS also uses a 7-bit field for storing the year value, with a different epoch counting from 1904, resulting in a maximum year of 2031 (1904+127).<ref>{{cite web|title=subject:RE: Date limited to 2031|url=https://www.mail-archive.com/search?l=palm-dev-forum@news.palmos.com&q=subject:%22Re%5C%3A+Date+limited+to+2031%22&o=newest&f=1|website=www.mail-archive.com|access-date=12 October 2019}}</ref> ] uses both ] integers with the 1970 ], as well as unsigned integers with the 1904 epoch, for different system functions,<ref>{{cite web|title=Palm OS® Protein C/C++ Compiler Language & Library Reference |url=http://apitechwriter.com/Samples/PalmSource/PalmOS_API_Compiler_Ref.pdf|access-date=12 October 2019|ref=Page 232}}</ref> such as for system clock, and file dates (see ]). While this should result in Palm OS being susceptible to the ], Palm OS also uses a 7-bit field for storing the year value, with a different epoch counting from 1904, resulting in a maximum year of 2031 (1904&nbsp;+&nbsp;127).<ref>{{cite web|title=subject:RE: Date limited to 2031|url=https://www.mail-archive.com/search?l=palm-dev-forum@news.palmos.com&q=subject:%22Re%5C%3A+Date+limited+to+2031%22&o=newest&f=1|website=mail-archive.com|access-date=12 October 2019}}</ref>

== Year 2034 ==
Some (if not all) ] phones only support dates up to 31 December 2033.{{Citation needed|date=July 2022}}


== Year 2036 == == Year 2036 ==
{{See also|Network Time Protocol#Timestamps}} {{See also|Network Time Protocol#Timestamps}}
The Network Time Protocol has an overflow issue related to the ], which manifests itself at 06:28:16 UTC on 7 February 2036, rather than 2038. The 64-bit timestamps used by NTP consist of a 32-bit part for seconds and a 32-bit part for fractional second, giving NTP a time scale that rolls over every 2{{sup|32}} seconds (136 years) and a theoretical resolution of 2{{sup|−32}} second (233 picoseconds). NTP uses an epoch of 1 January 1900. The first rollover occurs in 2036, prior to the UNIX year 2038 problem.<ref>{{cite web|url=https://www.eecis.udel.edu/~mills/y2k.html|author=David L. Mills|title=The NTP Era and Era Numbering|date=12 May 2012|access-date=24 September 2016}}</ref><ref>{{cite book|author1=W. Richard Stevens|author2=Bill Fenner|author3=Andrew M. Rudoff|title=UNIX Network Programming|url=https://books.google.com/books?id=ptSC4LpwGA0C&pg=PA582|year=2004|publisher=Addison-Wesley Professional|isbn=978-0-13-141155-5|pages=582–}}</ref> The Network Time Protocol has an overflow issue related to the ], which manifests itself at 06:28:16&nbsp;UTC on 7&nbsp;February 2036, rather than 2038. The 64-bit timestamps used by NTP consist of a 32-bit part for seconds and a 32-bit part for fractional second, giving NTP a time scale that rolls over every 2{{sup|32}} seconds (136&nbsp;years) and a theoretical resolution of 2{{sup|−32}} second (233&nbsp;picoseconds). NTP uses an epoch of 1&nbsp;January 1900. The first rollover occurs in 2036, prior to the UNIX year 2038 problem.<ref name="csdates" /><ref>{{cite web |url=https://www.eecis.udel.edu/~mills/y2k.html|author=David L. Mills|title=The NTP Era and Era Numbering|date=12 May 2012|access-date=24 September 2016}}</ref><ref>{{cite book|author1=W. Richard Stevens|author2=Bill Fenner|author3=Andrew M. Rudoff|title=UNIX Network Programming |url=https://books.google.com/books?id=ptSC4LpwGA0C&pg=PA582|year=2004|publisher=Addison-Wesley Professional|isbn=978-0-13-141155-5|pages=582–}}</ref>


== Year 2038 == == Year 2038 ==
=== Unix time rollover === === Unix time rollover ===
{{main|Year 2038 problem}} {{main|Year 2038 problem}}
The original implementation of the ] operating system stored system time as a ] representing the number of seconds past the ]: midnight UTC 00:00:00 on Thursday, 1 January 1970. This value will roll over after 03:14:07 UTC on Tuesday, 19 January 2038. This problem has been addressed in most modern Unix and ] operating systems by storing system time as a 64-bit signed integer, although individual applications, protocols, and file formats will still need to be changed as well. The original implementation of the ] operating system stored system time as a ] representing the number of seconds past the ] (1 January 1970, 00:00:00&nbsp;UTC). This value will roll over after 19&nbsp;January 2038, 03:14:07&nbsp;UTC. This problem has been addressed in most modern Unix and ] operating systems by storing system time as a 64-bit signed integer, although individual applications, protocols, and file formats must be changed as well.


=== Windows C runtime library === === Windows C runtime library ===
Like the Unix time rollover issue, the 32-bit version of gmtime in the C runtime libraries on Windows has a similar problem.<ref>{{cite web|title=gmtime, _gmtime32, _gmtime64|url=https://docs.microsoft.com/en-us/cpp/c-runtime-library/reference/gmtime-gmtime32-gmtime64?view=msvc-170|publisher=Microsoft|access-date=8 April 2022}}</ref> Like the Unix time rollover issue, the 32-bit version of gmtime in the C runtime libraries on Windows has a similar problem.<ref>{{cite web |title=gmtime, _gmtime32, _gmtime64|url=https://docs.microsoft.com/en-us/cpp/c-runtime-library/reference/gmtime-gmtime32-gmtime64?view=msvc-170 |publisher=Microsoft|access-date=8 April 2022}}</ref>


This problem has already manifested in ] Access Manager version 10.1.4.3 for Windows. The Identity Console component sets a cookie containing ] preferences with an expiry of 500,000,000 seconds in the future (just over 15 years, 308 days, 53 minutes and 20 seconds). This is beyond 19 January 2038 and so it throws an ] for certain search activities after 17 March 2022 at 02:20:48 because the gmtime_r() call cannot convert the number provided to a date to write to the cookie.<ref>{{cite web|title=Oracle Access Manager - Oracle tech|url=https://community.oracle.com/tech/apps-infra/discussion/comment/16831833|website=Oracle Communities|publisher=Oracle Corporation|access-date=8 April 2022}}</ref> Despite the age of the software (18 June 2009), Oracle issued a patch number 33983548 on 6 April 2022. This problem has already manifested in ] Access Manager version 10.1.4.3 for Windows. The Identity Console component sets a cookie containing ] preferences with an expiry of 500,000,000&nbsp;seconds in the future (approximately 16&nbsp;years). This is beyond 19&nbsp;January 2038 and so it throws an ] for certain search activities after 02:20:48&nbsp;UTC on 17&nbsp;March 2022 because the gmtime_r() call cannot convert the number provided to a date to write to the cookie.<ref>{{cite web|title=Oracle Access Manager |url=https://forums.oracle.com/ords/apexds/post/oracle-access-manager-5412#323523248071078005693687052982423282497 |website=Oracle Communities |date=24 March 2022 |publisher=Oracle Corporation|access-date=25 February 2023}}</ref> Despite the age of the software (18 June 2009), Oracle issued a patch number 33983548 on 6&nbsp;April 2022.

=== DVB rollover ===
{{expand section|date=September 2020}}
The ] system has an issue on 22 April 2038, when the 16 bits used to transmit ]s used for electronic guide scheduling will restart from zero. The ] EN 300 368 specification mentions in Annex C that the provided MJD formulas are valid until 28 February 2100, but makes no mention of the limits imposed by the 16 bits used to transmit the resulting value.{{citation needed|date=September 2015}}


=== Third GPS rollover === === Third GPS rollover ===
The third ] will occur between 20 November 2038 and 21 November 2038. The third ] will occur at 20&nbsp;November 2038, at 23:59:37&nbsp;UTC.


== Year 2040 == == Year 2040 ==
Early Apple ] computers store time in their ]s (RTCs) and ] filesystems as an unsigned 32-bit number of seconds since 00:00:00 on 1 January 1904. After 06:28:15 on 6 February 2040 (i.e. 2<sup>32</sup>-1 seconds from the epoch), this will wrap around to 1904:<ref name=inside>Apple Computer, Inc., ''Inside Macintosh'', Volume II, Addison Wesley, 1985, p. 369</ref> further to this, ], the default format for all of Apple's recent Macintosh computers, is also affected. The replacement ] resolves this issue. All Apple ] computers store time in their ]s (RTCs) and ] filesystems as an unsigned 32-bit number of seconds since 00:00:00 on 1&nbsp;January 1904. After 06:28:15 on 6&nbsp;February 2040, (i.e. {{nowrap|2<sup>32</sup> &minus; 1}} seconds from the epoch), this will wrap around to 1904:<ref name="csdates" /><ref name="inside">Apple Computer, Inc., ''Inside Macintosh'', Volume II, Addison Wesley, 1985, p. 369</ref> further to this, ], the default format for all of Apple's recent Mac computers, is also affected. The replacement ] resolves this issue.


ProDOS for the ] computers only supports two-digit year numbers. To avoid Y2K issues, Apple issued a technical note stating that the year number was to represent 1940–2039.<ref>{{cite web|url=http://www.1000bit.it/support/manuali/apple/technotes/pdos/tn.pdos.28.html|title=ProDOS Dates -- 2000 and Beyond |publisher=Apple, Inc.|access-date=6 December 2019}}</ref> Software for the platform may incorrectly display dates beginning in 2040, though a third-party effort is underway to update ProDOS and application software to support years up to 4095.<ref>{{cite web|url=https://prodos8.com/releases/prodos-25/|title=ProDOS 2.5|access-date=9 June 2021}}</ref> ProDOS for the ] computers only supports two-digit year numbers. To avoid Y2K issues, Apple issued a technical note stating that the year number was to represent 1940–2039.<ref>{{cite web|url=http://www.1000bit.it/support/manuali/apple/technotes/pdos/tn.pdos.28.html|title=ProDOS Dates -- 2000 and Beyond |publisher=Apple, Inc.|access-date=6 December 2019}}</ref> Software for the platform may incorrectly display dates beginning in 2040, though a third-party effort is underway to update ProDOS and application software to support years up to 4095.<ref>{{cite web|url=https://prodos8.com/releases/prodos-25/|title=ProDOS 2.5|access-date=9 June 2021}}</ref>


== Year 2042 == == Year 2042 ==
On 18 September 2042, the Time of Day Clock (TODC) on the S/370 ] and its successors, including the current zSeries, will roll over.<ref name=Lascu>{{Citation|title=Server Time Protocol Planning Guide|edition=4th|url=http://www.redbooks.ibm.com/abstracts/sg247280.html|publisher=]|series=IBM Redbooks|first1=Octavian|last1=Lascu|first2=Hans-Peter|last2=Eckam|first3=George|last3=Kozakos|first4=Paulo Vitor|last4=Pereira|isbn=978-0738438108|date=June 2013|access-date=11 August 2019|page=19}}</ref> On 18&nbsp;September 2042, the Time of Day Clock (TODC) on the S/370 ] and its successors, including the current zSeries, will roll over.<ref name="csdates" /><ref name="Lascu">{{Citation |title=Server Time Protocol Planning Guide |edition=4th |publisher=] |series=IBM Redbooks |first1=Octavian |last1=Lascu |first2=Hans-Peter |last2=Eckam |first3=George |last3=Kozakos |first4=Paulo Vitor |last4=Pereira |isbn=978-0738438108 |date=June 2013 |url=http://www.redbooks.ibm.com/abstracts/sg247280.html|access-date=11 August 2019|page=19}}</ref>


Older TODCs were implemented as a 64-bit count of 2{{sup|−12}} microsecond (0.244 ns) units, and the standard base was 1 January 1900 ]. In July 1999 the extended TODC clock was announced, which extended the clock to the right (that is, the extended bits are less significant than the original bits). The actual resolution depends on the model, but the format is consistent, and will, therefore, roll over after 2{{sup|52}} microseconds.<ref name=Lascu/> Older TODCs were implemented as a 64-bit count of 2{{sup|−12}} microsecond (0.244 ns) units, and the standard base was 1&nbsp;January 1900, ]. In July 1999 the extended TODC clock was announced, which extended the clock to the right (that is, the extended bits are less significant than the original bits). The actual resolution depends on the model, but the format is consistent, and will, therefore, roll over after 2{{sup|52}} microseconds.<ref name="Lascu" />


The TODC value is accessible to user mode programs and is often used for timing and for generating unique IDs for events. The TODC value is accessible to user mode programs and is often used for timing and for generating unique IDs for events.
Line 153: Line 148:


== Year 2048 == == Year 2048 ==
The capacity planning logic in the ERP system ] supports only finish dates up to 19&nbsp;January 2048, (24,855&nbsp;days from 1&nbsp;January 1980, corresponding to 2<sup>31</sup> seconds rounded down to full days). This concerns e.g. the production, maintenance and inspection planning.<ref>{{cite web|url=https://launchpad.support.sap.com/#/notes/2258792|title=SAP note 2258792 (access to SAP Support Portal required)|date=30 November 2018}}</ref>
The ] system will have an issue similar to the DVB issue described above after 2048 due to its use of signed 32-bit GPS seconds that begin from 6 January 1980.


== Year 2069 ==
The capacity planning logic in the ERP system ] supports only finish dates up to 19 January 2048 (24,855 days from 1 January 1980). This concerns e.g. the production, maintenance and inspection planning.<ref>{{cite web|url=https://launchpad.support.sap.com/#/notes/2258792|title=SAP note 2258792 (access to SAP Support Portal required)|date=30 November 2018}}</ref>
According to the ] for parsing two-digit years using ], "values in the range shall refer to years 1969 to 1999 inclusive and values in the range shall refer to years 2000 to 2068 inclusive",<ref name="csdates" /><ref>{{cite web |title=strptime - The Open Group Base Specifications Issue 7, 2018 edition |url=https://pubs.opengroup.org/onlinepubs/9699919799/functions/strptime.html |access-date=4 March 2023}}</ref> meaning that, when parsed by {{code|strptime()}}, the two-digit year "69" would be interpreted as 1969 rather than 2069.


==Year 2079== == Year 2079 ==
=== Days 32,768 and 65,536 === === Days 32,768 and 65,536 ===
Programs that store dates as the number of days since an arbitrary date (or '']'') are vulnerable to roll-over or wrap-around effects if the values are not wide enough to allow the date values to span a large enough time range expected for the application. Signed 16-bit binary values roll over after 32,768 (2{{sup|15}}) days from the epoch date, producing negative values. Some mainframe systems experienced software failures because they had encoded dates as the number of days since 1 January 1900, which produced unexpected negative day numbers on the roll-over date of 18 September 1989. Similarly, unsigned 16-bit binary days counts ] after 65,536 (2{{sup|16}}) days, which are truncated to zero values. For software using an epoch of 1 January 1900, this will occur on 6 June 2079.<ref>{{cite web|url=http://www.merlyn.demon.co.uk/critdate.htm|title=Critical and Significant Dates|author=J. R. Stockton|date=12 April 2009|access-date=20 August 2009|url-status=dead|archive-url=https://web.archive.org/web/20150907215822/http://www.merlyn.demon.co.uk/critdate.htm|archive-date=7 September 2015}}</ref> Programs that store dates as the number of days since an arbitrary date (or '']'') are vulnerable to roll-over or wrap-around effects if the values are not wide enough to allow the date values to span a large enough time range expected for the application. Signed 16-bit binary values roll over after 32,768 (2{{sup|15}}) days from the epoch date, producing negative values. Some mainframe systems experienced software failures because they had encoded dates as the number of days since 1&nbsp;January 1900, which produced unexpected negative day numbers on the roll-over date of 18&nbsp;September 1989. Similarly, unsigned 16-bit binary days counts ] after 65,536 (2{{sup|16}}) days, which are truncated to zero values. For software using an epoch of 1&nbsp;January 1900, this will occur on 6&nbsp;June 2079.<ref name="csdates" />


== Year 2080 == == Year 2080 ==
Some (if not all) Nokia phones that run ] (such as the ]) only support dates up to 31 December 2079, and thus will be unable to display dates after this. One workaround is to use the year 1996, 2024 or 2052 in lieu of 2080 (as compatible leap years) to display the correct day of the week, date and month on the main screen. Some (if not all) Nokia phones that run ] (such as the ]) only support dates up to 31&nbsp;December 2079, and thus will be unable to display dates after this. One workaround is to use the year 1996, 2024 or 2052 in lieu of 2080 (as compatible leap years) to display the correct day of the week, date and month on the main screen.{{Citation needed|date=December 2023}}


Systems storing the year as a two-digit value 00..99 internally only, like many RTCs, may roll over from 31 December 2079 to the IBM PC and DOS ]. Systems storing the year as a two-digit value 00..99 internally only, like many RTCs, may roll over from 31&nbsp;December 2079, to the IBM PC and DOS ].


== {{anchor|Year 2099}}Year 2100 == == {{anchor|Year 2099}}Year 2100 ==
{{See also|Leap year problem}}
{{Unreferenced section|date=August 2021}} {{Unreferenced section|date=August 2021}}
] and ] file date ] and conversion functions (such as ]/AH=2Ah) officially support dates up to 31 December 2099 only (even though the underlying ] would theoretically support dates up to 2107). Hence, DOS-based operating systems, as well as applications that convert other formats to the FAT/DOS format, may show unexpected behavior starting 1 January 2100. ] and ] file date ] and conversion functions (such as ]/AH=2Ah) officially support dates up to 31&nbsp;December 2099, only (even though the underlying ] would theoretically support dates up to 2107). Hence, DOS-based operating systems, as well as applications that convert other formats to the FAT/DOS format, may show unexpected behavior starting 1&nbsp;January 2100.


Likewise, the Nintendo DS and GameCube, as well as the Sony PlayStation 4, only allow users to set dates up to the year 2099. In the case of the Nintendo DS, the system will not advance time beyond 31&nbsp;December 2099, whereas the GameCube and PS4 will still roll over into 2100 and beyond, even though users of those game consoles cannot manually input the date and time that far out.
Another problem will emerge at the end of 28 February 2100, since 2100 is not a ]. As many common implementations of the leap year algorithm are incomplete or are simplified, they may erroneously assume 2100 to be a leap year, causing the date to roll over from 28 February 2100 to 29 February 2100 instead of 1 March 2100.


=== 2100 is not a leap year ===
The Nintendo DS and GameCube, as well as the Sony PlayStation 4, only allow users to set dates up to the year 2099. In the case of the Nintendo DS, the system will not advance time beyond 31 December 2099, whereas the GameCube and PS4 will still roll over into 2100 and beyond, even in spite of the fact that users of those game consoles cannot manually input the date and time that far out.
{{See also|Leap year problem}}
Another problem will emerge at the end of 28&nbsp;February 2100, since 2100 is not a ]. As many common implementations of the leap year algorithm are incomplete or are simplified, they may erroneously assume 2100 to be a leap year, causing the date to roll over from 28&nbsp;February 2100 to 29&nbsp;February 2100, instead of 1&nbsp;March 2100.

The DS3231 hardware RTC has the 2100 year problem, because it uses 2-digit to store the year.<ref>{{Cite web |title=DS3231 - Extremely Accurate I²C-Integrated RTC/TCXO/Crystal |url=https://www.analog.com/en/products/ds3231.html }}</ref>


== {{anchor|Year 2106}}Year 2106 == == {{anchor|Year 2106}}Year 2106 ==
Many existing file formats, communications protocols, and application interfaces employ a variant of the ] {{code|time_t}} date format, storing the number of seconds since the Unix Epoch (midnight UTC, 1 January 1970) as an ''unsigned'' 32-bit binary integer. This value will roll over on 7 February 2106 at 06:28:15. That is, at this time the number of seconds since 1 January 1970 is FFFF FFFF in hex. Many existing file formats, communications protocols, and application interfaces employ a variant of the ] {{code|time_t}} date format, storing the number of seconds since the Unix Epoch (midnight UTC, 1&nbsp;January 1970) as an ''unsigned'' 32-bit binary integer. This value will roll over on 7&nbsp;February 2106 at 06:28:16&nbsp;UTC. That is, at this time the number of seconds since 1&nbsp;January 1970 is FFFF FFFF in hex.<ref name="csdates" />


This storage representation problem is independent of programs that internally store and operate on system times as 64-bit signed integer values. This storage representation problem is independent of programs that internally store and operate on system times as 64-bit signed integer values.


== {{anchor|Year 2107}}Year 2108 == == {{anchor|Year 2107}}Year 2108 ==
The date timestamps stored in ]s, originally introduced with ] in 25 February 1981 and carried over into ], ], ] etc., will overflow at the end of 31 December 2107. The ] (and with ] 2.0+ also the ], and since ]+ optionally also the ] and ]), are stored in the ] with the year represented as an unsigned seven bit number (0–127), relative to 1980, and thereby unable to indicate any dates in the year 2108 and beyond. The ]s defined to retrieve these dates officially only support dates up to 31 December 2099. The date timestamps stored in ]s, originally introduced with ] in 1981 and carried over into ], ], ] etc., will overflow at the end of 31&nbsp;December 2107.<ref name="csdates" /> The ] (and with ] 2.0+ also the ], and since ]+ optionally also the ] and ]), are stored in the ] with the year represented as an unsigned seven bit number (0–127), relative to 1980, and thereby unable to indicate any dates in the year 2108 and beyond. The ]s defined to retrieve these dates officially only support dates up to 31&nbsp;December 2099.


This will also affect the ], as it uses FAT file modification timestamps internally. This will also affect the ], as it uses FAT file modification timestamps internally.


== {{anchor|Year 2137}}Year 2137 == == {{anchor|Year 2137}}Year 2137 ==
{{main|GPS week number rollover}} {{main|GPS week number rollover}}
{{See also|GPS#Timekeeping}} {{See also|GPS#Timekeeping}}
GPS dates are expressed as a week number and a day-of-week number, with the week number initially using a ten-] value and modernised GPS navigation messages using a 13-bit field. Ten-bit systems would roll over every 1024 weeks (about 19.6 years) after Sunday 6 January 1980 (the GPS ]), and 13-bit systems roll over every 8192 weeks. Thirteen-bit systems will roll over to zero in 2137.<ref name="tothenines"/><ref name=cybergovau/> GPS dates are expressed as a week number and a day-of-week number, with the week number initially using a ten-] value and modernised GPS navigation messages using a 13-bit field. Ten-bit systems would roll over every 1024 weeks (about 19.6&nbsp;years) after Sunday 6&nbsp;January 1980 (the GPS ]), and 13-bit systems roll over every 8192 weeks. Thirteen-bit systems will roll over to zero in 2137.<ref name="csdates" /><ref name="tothenines" /><ref name="cybergovau" />

== {{anchor|Year 2248}}Year 2248 ==
] stores dates as centiseconds (hundredths of a second) since 1&nbsp;January 1900 in five bytes (40 bits). These timestamps are used internally and exposed in file metadata (load and exec addresses).<ref>{{Cite web |last=Robertson |first=Alan |date=December 4, 2009 |orig-date=breadcrumbs modified on November 13, 2017 |title=OS_Word 14,3 (SWI &07) |url=https://www.riscosopen.org/documentation/show/OS_Word%2014_3 |url-status=live |archive-url=https://web.archive.org/web/20231129212626/https://www.riscosopen.org/documentation/show/OS_Word%2014_3 |archive-date=2023-11-29 |access-date=2024-10-01 |website=RISC OS Open Instiki}}</ref> This value will overflow on 3&nbsp;June 2248 at 06:57:57.75&nbsp;UTC.<ref name="csdates" />


== {{anchor|Year 2262}}Year 2262 == == {{anchor|Year 2262}}Year 2262 ==
Some timekeeping systems count ] since 1970 using a 64-bit signed integer, which will overflow at 11 April 2262 23:47:16. The ] {{code|UnixNano}} API is one example.<ref>{{Cite web|url=https://pkg.go.dev/time|title=time package - time|website=pkg.go.dev}}</ref> Other examples include the Timestamp object in Python ],<ref>{{Cite web|url=http://pandas.pydata.org/pandas-docs/stable/user_guide/timeseries.html#timestamp-limitations|title=Time series / Date functionality — pandas 1.3.4 documentation}}</ref> ] chrono::system_clock,<ref>{{Cite web|url=https://en.cppreference.com/w/cpp/chrono/system_clock|title=std::chrono::system_clock|website=en.cppreference.com}}</ref>{{Failed verification|talk=Year 2262 and C++ chrono::systemclock|date=March 2021}} and the ] timers.<ref>{{Cite web|url=https://git.qemu.org/?p=qemu.git%3Ba%3Dblob%3Bf%3Dinclude%2Fqemu%2Ftimer.h%3Bh%3D6a8b48b5a9%3Bhb%3Dv5.0.0#l85|title=Update version for v5.0.0 release|access-date=19 June 2021|archive-date=21 January 2021|archive-url=https://web.archive.org/web/20210121184655/https://git.qemu.org/?p=qemu.git%3Ba%3Dblob%3Bf%3Dinclude%2Fqemu%2Ftimer.h%3Bh%3D6a8b48b5a9%3Bhb%3Dv5.0.0#l85|url-status=dead }}</ref> Some high-resolution timekeeping systems count ] since {{nowrap|1 January 1970}} using a 64-bit signed integer, which will overflow on {{nowrap|11 April 2262}} at 23:47:16&nbsp;UTC. The ] {{code|UnixNano}} API is one example.<ref>{{Cite web|url=https://pkg.go.dev/time|title=time package time|website=pkg.go.dev}}</ref> Other examples include the Timestamp object in Python ],<ref>{{Cite web |url=http://pandas.pydata.org/pandas-docs/stable/user_guide/timeseries.html#timestamp-limitations|title=Time series / date functionality — pandas 2.2.3 documentation|website=pandas.pydata.org}}</ref> the <code>chrono</code> class in ] when set to nanosecond precision,<ref>{{Cite web |url=https://en.cppreference.com/w/cpp/chrono/duration#Helper_types |title=std::chrono::duration|website=en.cppreference.com}}</ref> and the ] timers.<ref>{{Cite web|url=https://git.qemu.org/?p=qemu.git%3Ba%3Dblob%3Bf%3Dinclude%2Fqemu%2Ftimer.h%3Bh%3D6a8b48b5a9%3Bhb%3Dv5.0.0#l85 |title=Update version for v5.0.0 release |access-date=19 June 2021|archive-date=21 January 2021|archive-url= https://web.archive.org/web/20210121184655/https://git.qemu.org/?p=qemu.git%3Ba%3Dblob%3Bf%3Dinclude%2Fqemu%2Ftimer.h%3Bh%3D6a8b48b5a9%3Bhb%3Dv5.0.0#l85 |url-status=dead }}</ref>


== Year 2286 == == Year 2286 ==
Systems that use a string of length 10 characters to record the ] maybe have a problems reporting times beyond the ten-billionth second after 20 November 2286 at 17:46:40 Systems that use a string of length 10 characters to record ] may have problems reporting times beyond 20&nbsp;November 2286, at 17:46:39&nbsp;UTC, ten billion seconds after the Unix epoch.<ref name="csdates" />

== Year 2446 ==
In ], the default file system for many Linux distributions, the bottom two bits of <code>{a,c,m}time_extra</code> are used to extend the <code>{a,c,m}time</code> fields, deferring the year 2038 problem to the year 2446.<ref>{{Cite web |url=https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=a4dad1ae24f850410c4e60f22823cba1289b8d52|title=ext4: Fix handling of extended tv_sec - kernel/git/stable/linux.git - Linux kernel stable tree|website=git.kernel.org}}</ref>
Within this "extra" 32-bit field, the lower two bits are used to extend the seconds field to a signed 34-bit integer; the upper 30 bits are used to provide nanosecond timestamp accuracy. Therefore, timestamps will not overflow until May 2446.<ref>{{Cite web |url=https://ext4.wiki.kernel.org/index.php/Ext4_Disk_Layout#Inode_Timestamps|title=Ext4 Disk Layout - Ext4 |website=ext4.wiki.kernel.org}}</ref>


== Years 4000, 8000, etc. == == Years 4000, 8000, etc. ==
On time scales of thousands of years, the Gregorian calendar falls behind the astronomical seasons. This is because ], which makes each day slightly longer over time (see ] and ]) while the year maintains a more uniform duration. On time scales of thousands of years, the Gregorian calendar falls behind the astronomical seasons. This is because ], which makes each day slightly longer over time (see ] and ]) while the year maintains a more uniform duration.


In the 19th century, Sir ] proposed a modification to the Gregorian calendar with 969 leap days every 4000 years, instead of 970 leap days that the Gregorian calendar would insert over the same period.<ref>{{cite book| first1= John |last1= Herschel |url=http://visualiseur.bnf.fr/Visualiseur?Destination=Gallica&O=NUMM-94926 |title= Outlines of Astronomy | year=1849 | page= 629}}</ref> This would reduce the average year to 365.24225 days. Herschel's proposal would make the year 4000, and multiples thereof, common instead of leap. While this modification has often been proposed since, it has never been officially adopted.<ref>{{cite book |last1=Steel |first1= Duncan |title=Marking Time: The Epic Quest to Invent the Perfect Calendar|year=2000|publisher=John Wiley & Sons|isbn=978-0-471-29827-4| page=185 |url=https://books.google.com/books?id=rxvVdXyr_hMC&pg=PA185}}</ref> In the 19th century, Sir ] proposed a modification to the Gregorian calendar with 969 leap days every 4,000&nbsp;years, instead of 970 leap days that the Gregorian calendar would insert over the same period.<ref>{{cite book| first1= John |last1= Herschel |url=http://visualiseur.bnf.fr/Visualiseur?Destination=Gallica&O=NUMM-94926 |title= Outlines of Astronomy | year=1849 | page= 629}}</ref> This would reduce the average year to 365.24225&nbsp;days. Herschel's proposal would make the year 4000, and multiples thereof, common instead of leap. While this modification has often been proposed since, it has never been officially adopted.<ref>{{cite book |last1=Steel |first1= Duncan |title=Marking Time: The Epic Quest to Invent the Perfect Calendar|year=2000|publisher=John Wiley & Sons|isbn=978-0-471-29827-4| page=185 |url=https://books.google.com/books?id=rxvVdXyr_hMC&pg=PA185}}</ref>


While most software (including ], ] and ]) currently recognizes 4000 and 8000 as leap years (as they are divisible by 400), ] has adopted the "4000 year rule". Thus, with the current software, date conversions between SAS and other software will go out of sync after 28 February 4000.<ref>'''', Chris Hemedinger</ref><ref>'''', SAS 9.4 documentation</ref> While most software (including ], ] and ]) currently recognizes 4000 and 8000 as leap years (as they are divisible by 400), ] has adopted the "4000&nbsp;year rule". Thus, with the current software, date conversions between SAS and other software will go out of sync after 28&nbsp;February 4000.<ref>{{cite web |url=http://blogs.sas.com/content/sasdummy/2010/04/05/in-the-year-9999/ |title=In the year 9999.... |author=Chris Hemedinger|date=5 April 2010 }}</ref><ref>{{cite web |url=https://documentation.sas.com/doc/en/pgmsascdc/9.4_3.5/acpcref/p0psac3j16cioen1nq2hkwrnk55y.htm#p1iyps015pshygn1k61itzash25f |title=Microsoft Access Database Files |at=The Conversion of Date and Time Values between SAS Data Sets and Microsoft Access Database |work=SAS 9.4 and SAS® Viya® 3.5 Programming Documentation}}</ref>


== {{anchor|Year 4501}}Year 4501== == {{anchor|Year 4501}}Year 4501 ==
] uses the date 1 January 4501 as a placeholder for "none" or "empty".<ref>{{Cite web|url=https://docs.microsoft.com/en-us/office/vba/api/Outlook.OlMarkInterval|title=OlMarkInterval enumeration (Outlook)}}</ref><ref>{{Cite web|url=https://docs.microsoft.com/en-us/office/vba/outlook/how-to/search-and-filter/filtering-items-using-query-keywords|title=Filtering Items Using Query Keywords}}</ref> ] uses the date 1&nbsp;January 4501 as a placeholder for "none" or "empty".<ref name="csdates" /><ref>{{Cite web|url=https://docs.microsoft.com/en-us/office/vba/api/Outlook.OlMarkInterval|title=OlMarkInterval enumeration (Outlook)|date=30 March 2022 }}</ref><ref>{{Cite web |url=https://docs.microsoft.com/en-us/office/vba/outlook/how-to/search-and-filter/filtering-items-using-query-keywords|title=Filtering Items Using Query Keywords|date=22 January 2022 }}</ref>


== Year 10,000 == == Year 10,000 ==
The year 10,000 will be the first Gregorian year with five digits. Although many people at first consider this year to be so far distant that a problem of this type will never actually occur, certain classes of calculations in disciplines such as ] and ] already need to work with years of this magnitude and greater. These applications also have to deal with the ]. All future years that are powers of 10 have the potential for similar problems. The year 10,000 will be the first Gregorian year with five digits. All future years that are powers of 10, as well as dates before the ], face similar encoding problems.


=== Examples ===
"RFC 2550 - Y10K and Beyond" discusses solutions for dealing with this problem. While this is one of the "April Fool" RFCs, it raises important points while dressed with a generous helping of humour.<ref>{{Cite journal|title=rfc2550|url=https://datatracker.ietf.org/doc/html/rfc2550|access-date=13 September 2021|website=datatracker.ietf.org|date=1 April 1999|last1=Glassman|first1=Steve|last2=Manasse|first2=Mark|last3=Mogul|first3=Jeffrey}}</ref>
This problem can be seen in the spreadsheet program ] as of 2023, which stores dates as the number of days since 31&nbsp;December 1899 (day 1 is 1&nbsp;January 1900) with a ] if using the default 1900 date system. Alternatively, if using the 1904 date system, the date is stored as the number of days since 1&nbsp;January 1904 (day 1 is 2&nbsp;January 1904), and there is no leap year problem. The maximum supported date for calculation is 31&nbsp;December 9999.<ref name="csdates" /><ref>{{Cite web| title=Differences between the 1900 and the 1904 date system – Office| work=Microsoft| access-date=22 February 2023| date=5 May 2022| url=https://learn.microsoft.com/en-us/office/troubleshoot/excel/1900-and-1904-date-system}}</ref><ref>{{Cite web| title=Excel specifications and limits| website=Microsoft Support| access-date=22 February 2023| url=https://support.microsoft.com/en-us/office/excel-specifications-and-limits-1672b34d-7043-467e-8e27-269d656771c3}}</ref>


== Year 30,828 == == Years 29,228 and 30,828 ==
In the ], the <code>DateTime</code> structure stores absolute timestamps as the number of 100-nanosecond intervals, known as "ticks", since midnight UTC on 1&nbsp;January ] in the ],<ref>{{Cite web |title=DateTime Struct (System) |url=https://learn.microsoft.com/en-us/dotnet/api/system.datetime?view=net-8.0 |access-date=2024-10-10 |website=learn.microsoft.com |language=en-us}}</ref> which will overflow on 14&nbsp;September 29,228 at 02:48:05.4775808&nbsp;UTC.<ref name="csdates" /><ref>{{Cite web |title=Working around accounts that expire with AAD Connect: REDUX |url=http://www.undocumented-features.com/2023/04/26/working-around-accounts-that-expire-with-aad-connect-redux/ |website=www.undocumented-features.com |language=en}}</ref> Many of Microsoft's applications and services have 100-nanosecond resolution for timekeeping, which will all face similar issues, such as ]'s <code>TIME</code> data type<ref>{{Cite web |title=List of data types for custom metrics |url=https://learn.microsoft.com/en-us/power-automate/minit/data-types-custom-metrics |access-date=2024-02-12 |website=learn.microsoft.com |date=18 July 2023 |language=en}}</ref> and the <code>TimeSpan</code> parameter in various ] commands.<ref>{{Cite web |title=Search-ADAccount |url=https://learn.microsoft.com/en-us/powershell/module/activedirectory/search-adaccount?view=windowsserver2019-ps#-timespan |access-date=2024-02-12 |website=learn.microsoft.com |language=en}}</ref>
Beginning 14 September 30,828, Windows will not accept dates beyond this day and on startup, it will display an error regarding "invalid system time" in NTFS. This is because the FILETIME value in Windows, which is a 64-bit value corresponding to the number of 100-nanosecond intervals since 1 January 1601, 00:00:00.0000000 UTC, will overflow its maximum possible value on that day at 02:48:05.4775808 UTC.<ref>{{Cite web|last=Thulin|first=Anders|title=Interpretation of NTFS Timestamps|work=Forensic Focus|access-date=23 July 2019|date=6 April 2013|url=https://articles.forensicfocus.com/2013/04/06/interpretation-of-ntfs-timestamps/}}</ref> This is because of ].

Similarly, in ] operating systems, the <code>FILETIME</code> structure stores the number of 100-nanosecond ticks since {{nowrap|1 January 1601}} as a signed 64-bit integer. This value will overflow on 14&nbsp;September 30,828 at 02:48:05&nbsp;UTC, after which Windows will not accept dates beyond this day and will display "invalid system time" errors in NTFS.<ref>{{Cite news |last=Thulin|first=Anders|title=Interpretation of NTFS Timestamps |work=Forensic Focus |date=6 April 2013 |url=http://articles.forensicfocus.com/2013/04/06/interpretation-of-ntfs-timestamps/|access-date=23 July 2019}}</ref>


== Years 32,768 and 65,536 == == Years 32,768 and 65,536 ==
Programs that process years as 16-bit values may encounter problems dealing with either the year 32,768 or 65,536, depending on whether the value is treated as a signed or unsigned integer. Programs that process years as 16-bit values may encounter problems dealing with either the year 32,768 or 65,536, depending on whether the value is treated as a signed or unsigned integer.


For the '''year 32,768 problem''', years after 32,767 may be interpreted as negative numbers, beginning with −32,768.<ref></ref> The '''year 65,536 problem''' is more likely to manifest itself by representing the year 65,536 as the year 0.<ref>{{cite web|url=http://libsnap.dom.edu/ClasPlus/ADDONS/Y2K.TXT|title=Folio TechNote|access-date=21 January 2008|url-status=dead|archive-url=https://web.archive.org/web/20080209230400/http://libsnap.dom.edu/ClasPlus/ADDONS/Y2K.TXT|archive-date=9 February 2008}}</ref> For the '''year 32,768 problem''', years after 32,767 may be interpreted as negative numbers,<ref name="csdates" /><ref>{{Cite web |url=http://delphi.about.com/od/humorandfun/a/funstopdelphi.htm |title=Top 10 Fun Reasons why you Should Stop Using Delphi, now! |access-date=21 January 2008 |archive-date=23 January 2008 |archive-url=https://web.archive.org/web/20080123080203/http://delphi.about.com/od/humorandfun/a/funstopdelphi.htm |url-status=dead }}</ref> beginning with −32,768 which may be displayed as 32,768&nbsp;]. The '''year 65,536 problem''' is more likely to manifest itself by the year 65,536 showing up as year 0.<ref name="csdates" /><ref>{{cite web|url=http://libsnap.dom.edu/ClasPlus/ADDONS/Y2K.TXT|title=Folio TechNote|access-date=21 January 2008|url-status=dead|archive-url=https://web.archive.org/web/20080209230400/http://libsnap.dom.edu/ClasPlus/ADDONS/Y2K.TXT|archive-date=9 February 2008}}</ref>

== Year 33,658 ==
Static library archives built by the <code>]</code> Unix command store timestamps as an ASCII string containing a decimal number of seconds past the ] (1 January 1970, 00:00:00&nbsp;UTC), with a limit of 12 ASCII characters. This value will roll over on 01:46:40&nbsp;UTC on {{nowrap|27 September 33658}}.<ref name="csdates" />


== Year 100,000 == == Year 100,000 ==
The Year 100,000 will be the first Gregorian year with six digits. The year 100,000 will be the first Gregorian year with six digits.


== Year 275,760 == == Year 275,760 ==
]'s Date API stores dates as the number of milliseconds since 1 January 1970. Dates have a range of ±100,000,000 days from the epoch, meaning that programs written in JavaScript using the Date API cannot store dates past 13 September, 275,760 CE.<ref>{{cite web|title=Date - Javascript |url=https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Date|website=MDN|access-date=5 July 2022}}</ref> ]'s Date API stores dates as the number of milliseconds since 1&nbsp;January 1970. Dates have a range of ±100,000,000&nbsp;days from the epoch, meaning that programs written in JavaScript using the Date API cannot store dates past 13&nbsp;September, AD&nbsp;275,760.<ref name="csdates" /><ref>{{cite web|title=Date Javascript |url=https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Date|website=MDN|access-date=5 July 2022}}</ref>


== Year 292,277,026,596 problem == == Year 292,277,026,596 ==
Certain problematic years occur so far in the future (well beyond the likely lifespan of the ], the ], humanity, and even past some predictions of the ]) that they are mainly referenced as matters of theoretical interest, jokes, or indications that a related problem is not truly solved for any reasonable definition of "solved". Systems that store Unix time in seconds using signed 64-bit integers will theoretically be able to represent dates and times up until 15:30:08&nbsp;UTC on Sunday, 4&nbsp;December, AD&nbsp;292,277,026,596.<ref name="csdates" /><ref>{{cite web|author=William Porquet|date=15 August 2007 |url=http://www.deepsky.com/~merovech/2038.html |title=Project 2038 FAQ |access-date=5 March 2010}}</ref><ref>{{cite web|title=Date/Time Conversion Contract Language |url=https://its.ny.gov/system/files/documents/2022/10/nys-p98-003_date_time_conversion_contract_language.pdf|publisher=Office of Information Technology Services, New York|access-date=25 February 2023|date=23 November 2021}}</ref> This year is so ] (well beyond the likely lifespan of the ], the ], humanity, and even past some predictions of the ]) that it is mainly referenced as a matter of theoretical interest, joke, or an indication that earlier versions like the year 2038 problem cannot be truly "solved" forever.


== Relative time overflow ==
The '''year 292,277,026,596 problem''' (about {{val|2.9e11}} years in the future) will occur when the 64-bit ] overflows after UTC 15:30:08 on Sunday, 4 December, 292,277,026,596 AD.<ref>{{cite web|url=http://www.deepsky.com/~merovech/2038.html|title=Project 2038 FAQ|access-date=5 March 2010|author=William Porquet|date=15 August 2007}}</ref><ref>{{cite web|title=Date/Time Conversion Contract Language|url=https://its.ny.gov/sites/default/files/documents/nys-p98-003_date_time_conversion_contract_language_1.pdf|publisher=Office of Information Technology Services, New York|access-date=16 October 2020|date=19 May 2019}}</ref>

==Relative time overflow==
=== Microsoft === === Microsoft ===
In Microsoft Windows 7, Windows Server 2003, Windows Server 2008 and Windows Vista, TCP connection start information was stored in hundredths of a second, using a 32-bit unsigned integer, causing an overflow and TCP connections to fail after 497 days.<ref>{{Cite web|url=https://support.microsoft.com/en-us/help/2553549/all-the-tcp-ip-ports-that-are-in-a-time-wait-status-are-not-closed-aft|title=All the TCP/IP ports that are in a TIME_WAIT status are not closed after 497 days from system startup in Windows Vista, in Windows 7, in Windows Server 2008 and in Windows Server 2008 R2}}</ref> In Microsoft Windows 7, Windows Server 2003, Windows Server 2008, and Windows Vista, TCP connection start information was stored in hundredths of a second, using a 32-bit unsigned integer, which caused TCP connections to fail after 497&nbsp;days.<ref>{{Cite web |url=https://support.microsoft.com/en-us/topic/all-the-tcp-ip-ports-that-are-in-a-time-wait-status-are-not-closed-after-497-days-from-system-startup-in-windows-vista-in-windows-7-in-windows-server-2008-and-in-windows-server-2008-r2-38c81adc-d990-c6f7-3689-91cca5d19a20|title=All the TCP/IP ports that are in a TIME_WAIT status are not closed after 497 days from system startup in Windows Vista, in Windows 7, in Windows Server 2008 and in Windows Server 2008 R2 - Microsoft Support|website=support.microsoft.com}}</ref>

Microsoft Windows 95 and Windows 98 had a problem with rollovers in a virtual device driver, <code>VTDAPI.VXD</code>, which used unsigned 32-bit integers to measure system runtime in milliseconds; this value would overflow after 49.7&nbsp;days, causing systems to freeze.<ref>{{Cite web |url=http://support.microsoft.com/support/kb/articles/q216/6/41.asp |title=Computer Hangs After 49.7 Days|date=8 May 1999|archive-url=https://web.archive.org/web/19990508050925/http://support.microsoft.com/support/kb/articles/q216/6/41.asp |archive-date=8 May 1999|url-status=dead}}</ref>


Until version 6.0, Microsoft's ] platform had a bug that caused threadpool hill-climbing{{clarify|date=December 2024}} to fail periodically after 49.7&nbsp;days due to an overflow while handling milliseconds since startup.<ref>{{Cite web |title=Hysteresis effect on threadpool hill-climbing · Issue #51935 · dotnet/runtime |url=https://github.com/dotnet/runtime/issues/51935 |access-date=2024-02-25 |website=GitHub |language=en}}</ref>
Microsoft Windows 95 and Windows 98 had a problem with 2^32 millisecond rollover in a virtual device driver (VTDAPI.VXD), which caused systems to hang after 49.7 days.<ref>{{Cite web|url=http://support.microsoft.com/support/kb/articles/q216/6/41.asp|title=Computer Hangs After 49.7 Days|date=8 May 1999|archive-url=https://web.archive.org/web/19990508050925/http://support.microsoft.com/support/kb/articles/q216/6/41.asp|archive-date=8 May 1999}}</ref>


=== Boeing === === Boeing ===
The ] aircraft has had at least two software issues related to time storage. In 2015, an error was reported where time was stored in hundredths of a second, using a signed 32-bit integer, and the systems would crash after 248 days.<ref>{{cite news|author=Edgar Alvarez|title=To keep a Boeing Dreamliner flying, reboot once every 248 days|url=https://www.engadget.com/2015/05/01/boeing-787-dreamliner-software-bug/|publisher=]|date=1 May 2015|access-date=2 April 2020}}</ref> The ] aircraft has had at least two software issues related to time storage. In 2015, an error was reported where system runtime was stored in hundredths of a second, using a signed 32-bit integer; this value would overflow after 248 days, after which the onboard generator control systems would crash, causing the aircraft to lose power.<ref>{{cite news|author=Edgar Alvarez|title=To keep a Boeing Dreamliner flying, reboot once every 248 days|url=https://www.engadget.com/2015/05/01/boeing-787-dreamliner-software-bug/|publisher=]|date=1 May 2015|access-date=2 April 2020}}</ref><ref>{{cite web |url=https://www.federalregister.gov/documents/2015/05/01/2015-10066/airworthiness-directives-the-boeing-company-airplanes |title=Airworthiness Directives; The Boeing Company Airplanes |website=Federal Register |date=May 2015 |language=en}}</ref>


In 2020, the ] issued an airworthiness directive for a problem where, if the aircraft is not powered down completely before reaching 51 days of uptime, systems will begin to display misleading data.<ref>{{cite web|author=Gareth Corfield|title=Boeing 787s must be turned off and on every 51 days to prevent 'misleading data' being shown to pilots|url = https://www.theregister.co.uk/2020/04/02/boeing_787_power_cycle_51_days_stale_data/|work=]|date=2 April 2020|access-date=2 April 2020}}</ref> In 2020, the ] issued an airworthiness directive requiring 787 operators to power their aircraft down completely before reaching 51&nbsp;days of uptime, since otherwise systems will begin to display misleading data.<ref>{{cite web|author=Gareth Corfield|title=Boeing 787s must be turned off and on every 51 days to prevent 'misleading data' being shown to pilots |url=https://www.theregister.co.uk/2020/04/02/boeing_787_power_cycle_51_days_stale_data/ |work=]|date=2 April 2020|access-date=2 April 2020}}</ref>


=== Arduino === === Arduino ===
The ] platform provides a relative time via the millis() function. This function returns an unsigned 32 bit value for "milliseconds since startup", which is designed to roll over every 49.71 days. By default, this is the only timing source available in the platform and programs need to take special care to handle rollovers.<ref>{{Cite web|date=22 March 2018|title=The Answer to the Arduino millis() Overflow/Wraparound Question|url=https://www.eeweb.com/the-answer-to-the-arduino-millis-overflow-wraparound-question/|website=EEWeb}}</ref> Internally, millis() is based on counting timer interrupts. Certain powersave modes disable interrupts and therefore stop the counter from advancing during sleep.<ref>{{Cite web|url=https://arduino.stackexchange.com/questions/76296/how-to-keep-track-of-millis-during-sleep-mode|title=Power - How to keep track of millis during sleep mode}}</ref> The ] platform provides relative time via the <code>millis()</code> function. This function returns an unsigned 32-bit integer representing "milliseconds since startup", which will roll over every 49&nbsp;days. By default, this is the only timing source available in the platform and programs need to take special care to handle rollovers.<ref>{{Cite web|date=22 March 2018|title=The Answer to the Arduino millis() Overflow/Wraparound Question |url=https://www.eeweb.com/the-answer-to-the-arduino-millis-overflow-wraparound-question/|website=EEWeb}}</ref> Internally, <code>millis()</code> is based on counting timer interrupts. Certain powersave modes disable interrupts and therefore stop the counter from advancing during sleep.<ref>{{Cite web |url=https://arduino.stackexchange.com/questions/76296/how-to-keep-track-of-millis-during-sleep-mode|title=How to keep track of millis during sleep mode|website=Arduino Stack Exchange}}</ref>


== Historic year problems == == Historic year problems ==
Also for historic years there might be problems when handling historic events, for example: Also for historic years there might be problems when handling historic events, for example:
*] * ]
*] * ]
*] * ]
*] * ]


== See also == == See also ==
Line 260: Line 272:


{{Year-related problems}} {{Year-related problems}}
{{Use dmy dates|date=November 2020}}


] ]

Latest revision as of 16:29, 4 January 2025

Class of software bugs

In computer science, data type limitations and software bugs can cause errors in time and date calculation or display. These are most commonly manifestations of arithmetic overflow, but can also be the result of other issues. The best-known consequence of this type is the Y2K problem, but many other milestone dates or times exist that have caused or will cause problems depending on various programming deficiencies.

Year 1975

On 5 January 1975, the 12-bit field that had been used for dates in the TOPS-10 operating system for DEC PDP-10 computers overflowed, in a bug known as "DATE75". The field value was calculated by taking the number of years since 1964, multiplying by 12, adding the number of months since January, multiplying by 31, and adding the number of days since the start of the month; putting 2 − 1 = 4095 into this gives 4 January 1975, which is therefore the latest encodable date. The "DATE-75" patch pushed the last encodable date to 1 February 2052, making the overflow date 2 February 2052, by using 3 spare bits from other fields in the file system's metadata, but this sometimes caused problems with software that used those bits for its own purposes. Some software may have supported using one additional bit for the date but had issues with additional bits, which could have resulted in some bugs on 9 January 1986.

Year 1978

The Digital Equipment Corporation OS/8 operating system for the PDP-8 computer used only three bits for the year, representing the years 1970 to 1977.

This was recognized when the COS-310 operating system was developed, and dates were recorded differently.

Year 1993

Multiple Sierra Entertainment games released for the Classic Mac OS started to freeze when running on 18 September 1993. An issue in the Mac version of Sierra's Creative Interpreter (Mac SCI) would cause the game to "lock-up" when attempting to handle a delay due to a problem involving an overflow. Mac SCI would attempt to use the date to determine how long a delay should last by getting the current time in seconds since 1 January 1904, the Macintosh epoch, and dividing by 12 hours. The division was processed by the Motorola 68000 and would not occur if an overflow was detected because of the division, but the Mac SCI would continue on regardless as if the division had occurred, eventually resulting in a delay of one second being treated as a delay for 18 hours and so on. Sierra released a patch called MCDATE that resolved the problem for almost 14 years.

Year 1997

In Apollo Computer's Domain/OS operating system, absolute time was stored as a signed 48-bit integer representing the number of 4-microsecond units since 1 January 1980. This value overflowed on 2 November 1997, rendering unpatched systems unusable.

Year 1999

In the last few months before the year 2000, two other date-related milestones occurred that received less publicity than the then-impending Y2K problem.

First GPS rollover

Main article: GPS week number rollover See also: GPS § Timekeeping

GPS dates are expressed as a week number and a day-of-week number, with the week number transmitted as a ten-bit value. This means that every 1,024 weeks (about 19.6 years) after Sunday 6 January 1980, (the GPS epoch), the date resets again to that date; this happened for the first time at 23:59:47 on 21 August 1999, the second time at 23:59:42 UTC on 6 April 2019, and will happen again on 20 November 2038. To address this concern, modernised GPS navigation messages use a 13-bit field, which only repeats every 8,192 weeks (157 years), and will not return to zero until the year 2137.

9/9/99

See also: Magic number (programming) and Magic string

Many legacy programs or data sets used "9/9/99" as a rogue value to indicate either an unresolved date or as a terminator to indicate no further data was in the set. This caused many systems to crash upon the arrival of the actual date this represents, 9 September 1999.

Year 2000

Two-digit year representations

Main article: Year 2000 problem See also: Year 1900 problem

The term year 2000 problem, or simply Y2K, refers to potential computer errors related to the formatting and storage of calendar data for dates in and after the year 2000. Many programs represented four-digit years with only the final two digits, making the year 2000 indistinguishable from 1900. Computer systems' inability to distinguish dates correctly had the potential to bring down worldwide infrastructures for computer reliant industries.

For applications required to calculate the birth year (or another past year), such an algorithm has long been used to overcome the Year 1900 problem, but it has failed to recognise people over 100 years old.

Year 2001

Systems that used a string of nine digits to record the time as seconds since the Unix epoch had issues reporting times beyond the one-billionth second after the epoch on 9 September 2001 at 01:46:40 (the "billennium"). Problems were not widespread.

Year 2007

Sierra Entertainment games for the Classic Mac OS that were patched with the MCDATE program or released afterwards with the patch built in would begin to freeze on 28 May 2007. As with the Year 1993 problem, this was due to an issue in the Mac SCI when attempting to use the date to determine how long a delay should last. Programs with the MCDATE patch freeze because the Mac SCI takes the current number of seconds since the Macintosh epoch of 1 January 1904, subtracts 432,000,000 seconds from that, and then divides by 12 hours through the Motorola 68000, to then determine how long delays should last. On 28 May 2007, the Motorola 68000 again does not divide due to overflow protection, which the Mac SCI ignores.

Year 2010

Some systems had problems once the year rolled over to 2010. This was dubbed by some in the media as the "Y2K+10" or "Y2.01k" problem.

The main source of problems was confusion between hexadecimal number encoding and BCD encodings of numbers. The numbers 0 through 9 are encoded in both hexadecimal and BCD as 0016 through 0916. But the decimal number 10 is encoded in hexadecimal as 0A16 and in BCD as 1016. Thus a BCD 1016 interpreted as a hexadecimal encoding erroneously represents the decimal number 16.

For example, the SMS protocol uses BCD encoding for dates, so some mobile phone software incorrectly reported dates of messages as 2016 instead of 2010. Windows Mobile was the first software reported to have been affected by this glitch; in some cases WM6 changed the date of any incoming SMS message sent after 1 January 2010, from the year 2010 to 2016.

Other systems affected include EFTPOS terminals, and the PlayStation 3 (except the Slim model).

Sony's PlayStation 3 incorrectly treated 2010 as a leap year, so the non-existent 29 February 2010, was shown on 1 March 2010, causing a program error.

The most important such glitch occurred in Germany, where upwards of 20 million bank cards became unusable, and with Citibank Belgium, whose digipass customer identification chips stopped working.

Year 2011

Main article: Year 2011 problem

Taiwan officially uses the Minguo calendar, which considers the Gregorian year 1912 to be its year 1. Thus, the Gregorian year 2011 is the ROC year 100, its first 3-digit year. This causes the year to appear to be 1911 (Year 0) if 2-digit representations are used.

Year 2013

The Deep Impact space probe lost communication with Earth on 11 August 2013, because of a time-tagging problem; the date was stored as an unsigned 32-bit integer counting the number of tenth-seconds since 1 January 2000.

Year 2019

Second GPS rollover

In 2019, the second GPS week number rollover occurred. Meade computerized telescope with GPS like the LX200GPS could no longer find their location and thus could not align themselves or locate stellar objects. Meade released a new firmware 4.2k with a fix but which also introduced many new bugs. 4.2l (little L, often confused with I) was released to fix that, but had more inexplicable changes. A 3rd party, StarPatch, released a hacked version of firmware 4.2g for free to fix the issues.

Japanese calendar transition

Main article: Japanese calendar era bug

On 30 April 2019, Emperor Akihito of Japan abdicated in favor of his son Naruhito. As years in Japan are traditionally referred to by era names that correspond to the reign of each emperor, this resulted in a new era name, Reiwa (令和), following Naruhito's accession to the throne the following day. Because the previous emperor, Hirohito, died 7 January 1989, and Akihito's reign mostly corresponded with the rise in the use of computers, most software had not been tested to ensure correct behavior on an era change, while testing was further complicated by the fact that the new era name was not revealed until 1 April 2019. Therefore, errors were expected from software that did not anticipate a new era.

Year 2020

The video games WWE 2K20 and Star Wars Jedi: Fallen Order both crashed on 1 January 2020, when the year rolled over. The glitches could only be circumvented by resetting the year back to 2019 until a patch was released. Additionally, Crystal Reports 8.5 would fail to generate specific reports starting in 2020.

Parkeon parking meters in New York City and other locations were unable to accept credit cards as a form of payment starting in 2020. A workaround was implemented, but required each meter to be individually updated. In New York, the meters were not expected to be fixed until 9 January.

In Poland, 5,000 cash registers stopped printing the date out properly.

Suunto sport smart watches displayed an error in computing weekdays that were presented with a +2 step (e.g. FRI rather than WED, SAT rather than THU). For Suunto Spartan model watches, the bug was fixed with firmware release 2.8.32.

Classic Mac OS

The control panel in Classic Mac OS versions 6, 7, and 8 only allows the date to be set as high as 31 December 2019, although the system is able to continue to advance time beyond that date.

Microsoft Schedule+

The first version of Microsoft Schedule+ as bundled with version 3.0 of the Microsoft Mail email client will refuse to work with years greater than 2020 or beyond, due to the fact that the program was designed to operate within a 100-year time window ranging from 1920 to 2019. As a result, the date can only be set as high as 31 December 2019.

Year 2021

Samsung users reported that phones running on the latest One UI 3.0 update or Android 11 lost access to the battery and charging statistics starting in 2021. Affected devices would not report usage statistics, thus leaving those sections blank.

Year 2022

Dates that are stored in the format yymmddHHMM converted to a signed 32-bit integer overflowed on 1 January 2022, since 2 = 2147483648. Notably affected was the malware-scanning component update numbers of Microsoft Exchange, which appear to be used for a mathematical check to determine the latest update.

Honda and Acura cars manufactured between 2004 and 2012 containing GPS navigation systems incorrectly displayed the year as 2002. This problem was due to an overflow on the GPS epoch. The issue was resolved on August 17, 2022.

Year 2024

Payment card readers at petrol pumps in New Zealand were unable to handle the leap year and were unable to properly dispense gasoline.

Video games EA Sports WRC and Theatrhythm Final Bar Line also suffered issues related to the leap year, with the former crashing when trying to load the game and the latter claiming that the save data was corrupted. Both games had to be set to the following day of March 1, 2024 to properly work.

In December 2024, a 30 year old bug was found in all versions of HCL Notes. When the server is started on or after December 13 2024, an overflow will prevent the mail router to load its configuration, and so no mail is delivered. Patches were released on the next day for all supported versions.

Year 2025

In Japan, some older computer systems using the Japanese calendar that have not been updated still count years according to the Shōwa era. The year 2025 corresponds in those systems to Shōwa 100, which can cause problems if the software assumes two digits for the year.

In Spain, all Talgo AVRIL class trains stopped operating on January 1, 2025 due to a date handling bug in the battery charging module, causing delays and cancellations as passengers were relocated in other rolling stock. A bugfix was deployed by the next day, recovering regular service.

Year 2028

Some systems store their year as a single-byte offset from 1900, which gives a range of 255 (8 bits) and allows dates up to 2155 to be safely represented. However, not all systems use an unsigned byte: some have been mistakenly coded with a signed byte which only allows a range of 127 years, meaning that the date field in the software will be incorrect after 2027 and can cause unpredictable behaviour. Several pieces of optical-disc software that operate using the ISO 9660 format are affected by this.

During the late 1970s, on Data General Nova and Eclipse systems, the World Computer Corporation (doing credit union applications) created a date format with a 16-bit date field, which used seven bits for the year, four bits for the month, and five bits for the day. This allowed dates to be directly comparable using unsigned functions. Some systems, including HP 3000, still use this format, although a patch has been developed by outside consultants.

Year 2032

Palm OS uses both signed integers with the 1970 epoch, as well as unsigned integers with the 1904 epoch, for different system functions, such as for system clock, and file dates (see PDB format). While this should result in Palm OS being susceptible to the 2038 problem, Palm OS also uses a 7-bit field for storing the year value, with a different epoch counting from 1904, resulting in a maximum year of 2031 (1904 + 127).

Year 2036

See also: Network Time Protocol § Timestamps

The Network Time Protocol has an overflow issue related to the Year 2038 problem, which manifests itself at 06:28:16 UTC on 7 February 2036, rather than 2038. The 64-bit timestamps used by NTP consist of a 32-bit part for seconds and a 32-bit part for fractional second, giving NTP a time scale that rolls over every 2 seconds (136 years) and a theoretical resolution of 2 second (233 picoseconds). NTP uses an epoch of 1 January 1900. The first rollover occurs in 2036, prior to the UNIX year 2038 problem.

Year 2038

Unix time rollover

Main article: Year 2038 problem

The original implementation of the Unix operating system stored system time as a 32-bit signed integer representing the number of seconds past the Unix epoch (1 January 1970, 00:00:00 UTC). This value will roll over after 19 January 2038, 03:14:07 UTC. This problem has been addressed in most modern Unix and Unix-like operating systems by storing system time as a 64-bit signed integer, although individual applications, protocols, and file formats must be changed as well.

Windows C runtime library

Like the Unix time rollover issue, the 32-bit version of gmtime in the C runtime libraries on Windows has a similar problem.

This problem has already manifested in Oracle's Access Manager version 10.1.4.3 for Windows. The Identity Console component sets a cookie containing UI preferences with an expiry of 500,000,000 seconds in the future (approximately 16 years). This is beyond 19 January 2038 and so it throws an exception for certain search activities after 02:20:48 UTC on 17 March 2022 because the gmtime_r() call cannot convert the number provided to a date to write to the cookie. Despite the age of the software (18 June 2009), Oracle issued a patch number 33983548 on 6 April 2022.

Third GPS rollover

The third GPS week number rollover will occur at 20 November 2038, at 23:59:37 UTC.

Year 2040

All Apple Mac computers store time in their real-time clocks (RTCs) and HFS filesystems as an unsigned 32-bit number of seconds since 00:00:00 on 1 January 1904. After 06:28:15 on 6 February 2040, (i.e. 2 − 1 seconds from the epoch), this will wrap around to 1904: further to this, HFS+, the default format for all of Apple's recent Mac computers, is also affected. The replacement Apple File System resolves this issue.

ProDOS for the Apple II computers only supports two-digit year numbers. To avoid Y2K issues, Apple issued a technical note stating that the year number was to represent 1940–2039. Software for the platform may incorrectly display dates beginning in 2040, though a third-party effort is underway to update ProDOS and application software to support years up to 4095.

Year 2042

On 18 September 2042, the Time of Day Clock (TODC) on the S/370 IBM mainframe and its successors, including the current zSeries, will roll over.

Older TODCs were implemented as a 64-bit count of 2 microsecond (0.244 ns) units, and the standard base was 1 January 1900, UT. In July 1999 the extended TODC clock was announced, which extended the clock to the right (that is, the extended bits are less significant than the original bits). The actual resolution depends on the model, but the format is consistent, and will, therefore, roll over after 2 microseconds.

The TODC value is accessible to user mode programs and is often used for timing and for generating unique IDs for events.

While IBM has defined and implemented a longer (128-bit) hardware format on recent machines, which extends the timer on both ends by at least 8 additional bits, many programs continue to rely on the 64-bit format which remains as an accessible subset of the longer timer.

Year 2048

The capacity planning logic in the ERP system SAP S/4HANA supports only finish dates up to 19 January 2048, (24,855 days from 1 January 1980, corresponding to 2 seconds rounded down to full days). This concerns e.g. the production, maintenance and inspection planning.

Year 2069

According to the Single UNIX Specification for parsing two-digit years using strptime(), "values in the range shall refer to years 1969 to 1999 inclusive and values in the range shall refer to years 2000 to 2068 inclusive", meaning that, when parsed by strptime(), the two-digit year "69" would be interpreted as 1969 rather than 2069.

Year 2079

Days 32,768 and 65,536

Programs that store dates as the number of days since an arbitrary date (or epoch) are vulnerable to roll-over or wrap-around effects if the values are not wide enough to allow the date values to span a large enough time range expected for the application. Signed 16-bit binary values roll over after 32,768 (2) days from the epoch date, producing negative values. Some mainframe systems experienced software failures because they had encoded dates as the number of days since 1 January 1900, which produced unexpected negative day numbers on the roll-over date of 18 September 1989. Similarly, unsigned 16-bit binary days counts overflow after 65,536 (2) days, which are truncated to zero values. For software using an epoch of 1 January 1900, this will occur on 6 June 2079.

Year 2080

Some (if not all) Nokia phones that run Series 40 (such as the Nokia X2-00) only support dates up to 31 December 2079, and thus will be unable to display dates after this. One workaround is to use the year 1996, 2024 or 2052 in lieu of 2080 (as compatible leap years) to display the correct day of the week, date and month on the main screen.

Systems storing the year as a two-digit value 00..99 internally only, like many RTCs, may roll over from 31 December 2079, to the IBM PC and DOS epoch of 1980-01-01.

Year 2100

This section does not cite any sources. Please help improve this section by adding citations to reliable sources. Unsourced material may be challenged and removed. (August 2021) (Learn how and when to remove this message)

DOS and Windows file date API and conversion functions (such as INT 21h/AH=2Ah) officially support dates up to 31 December 2099, only (even though the underlying FAT filesystem would theoretically support dates up to 2107). Hence, DOS-based operating systems, as well as applications that convert other formats to the FAT/DOS format, may show unexpected behavior starting 1 January 2100.

Likewise, the Nintendo DS and GameCube, as well as the Sony PlayStation 4, only allow users to set dates up to the year 2099. In the case of the Nintendo DS, the system will not advance time beyond 31 December 2099, whereas the GameCube and PS4 will still roll over into 2100 and beyond, even though users of those game consoles cannot manually input the date and time that far out.

2100 is not a leap year

See also: Leap year problem

Another problem will emerge at the end of 28 February 2100, since 2100 is not a leap year. As many common implementations of the leap year algorithm are incomplete or are simplified, they may erroneously assume 2100 to be a leap year, causing the date to roll over from 28 February 2100 to 29 February 2100, instead of 1 March 2100.

The DS3231 hardware RTC has the 2100 year problem, because it uses 2-digit to store the year.

Year 2106

Many existing file formats, communications protocols, and application interfaces employ a variant of the Unix time_t date format, storing the number of seconds since the Unix Epoch (midnight UTC, 1 January 1970) as an unsigned 32-bit binary integer. This value will roll over on 7 February 2106 at 06:28:16 UTC. That is, at this time the number of seconds since 1 January 1970 is FFFF FFFF in hex.

This storage representation problem is independent of programs that internally store and operate on system times as 64-bit signed integer values.

Year 2108

The date timestamps stored in FAT filesystems, originally introduced with 86-DOS 0.42 in 1981 and carried over into MS-DOS, PC DOS, DR-DOS etc., will overflow at the end of 31 December 2107. The last modification date stamp (and with DELWATCH 2.0+ also the file deletion date stamp, and since DOS 7.0+ optionally also the last access date stamp and creation date stamp), are stored in the directory entry with the year represented as an unsigned seven bit number (0–127), relative to 1980, and thereby unable to indicate any dates in the year 2108 and beyond. The API functions defined to retrieve these dates officially only support dates up to 31 December 2099.

This will also affect the ZIP archive file format, as it uses FAT file modification timestamps internally.

Year 2137

Main article: GPS week number rollover See also: GPS § Timekeeping

GPS dates are expressed as a week number and a day-of-week number, with the week number initially using a ten-bit value and modernised GPS navigation messages using a 13-bit field. Ten-bit systems would roll over every 1024 weeks (about 19.6 years) after Sunday 6 January 1980 (the GPS epoch), and 13-bit systems roll over every 8192 weeks. Thirteen-bit systems will roll over to zero in 2137.

Year 2248

RISC OS stores dates as centiseconds (hundredths of a second) since 1 January 1900 in five bytes (40 bits). These timestamps are used internally and exposed in file metadata (load and exec addresses). This value will overflow on 3 June 2248 at 06:57:57.75 UTC.

Year 2262

Some high-resolution timekeeping systems count nanoseconds since 1 January 1970 using a 64-bit signed integer, which will overflow on 11 April 2262 at 23:47:16 UTC. The Go programming language's UnixNano API is one example. Other examples include the Timestamp object in Python pandas, the chrono class in C++ when set to nanosecond precision, and the QEMU timers.

Year 2286

Systems that use a string of length 10 characters to record Unix time may have problems reporting times beyond 20 November 2286, at 17:46:39 UTC, ten billion seconds after the Unix epoch.

Year 2446

In ext4, the default file system for many Linux distributions, the bottom two bits of {a,c,m}time_extra are used to extend the {a,c,m}time fields, deferring the year 2038 problem to the year 2446. Within this "extra" 32-bit field, the lower two bits are used to extend the seconds field to a signed 34-bit integer; the upper 30 bits are used to provide nanosecond timestamp accuracy. Therefore, timestamps will not overflow until May 2446.

Years 4000, 8000, etc.

On time scales of thousands of years, the Gregorian calendar falls behind the astronomical seasons. This is because the Earth's speed of rotation is gradually slowing down, which makes each day slightly longer over time (see tidal acceleration and leap second) while the year maintains a more uniform duration.

In the 19th century, Sir John Herschel proposed a modification to the Gregorian calendar with 969 leap days every 4,000 years, instead of 970 leap days that the Gregorian calendar would insert over the same period. This would reduce the average year to 365.24225 days. Herschel's proposal would make the year 4000, and multiples thereof, common instead of leap. While this modification has often been proposed since, it has never been officially adopted.

While most software (including Excel, JavaScript and R) currently recognizes 4000 and 8000 as leap years (as they are divisible by 400), SAS has adopted the "4000 year rule". Thus, with the current software, date conversions between SAS and other software will go out of sync after 28 February 4000.

Year 4501

Microsoft Outlook uses the date 1 January 4501 as a placeholder for "none" or "empty".

Year 10,000

The year 10,000 will be the first Gregorian year with five digits. All future years that are powers of 10, as well as dates before the 10th millennium BC, face similar encoding problems.

Examples

This problem can be seen in the spreadsheet program Microsoft Excel as of 2023, which stores dates as the number of days since 31 December 1899 (day 1 is 1 January 1900) with a fictional leap day in 1900 if using the default 1900 date system. Alternatively, if using the 1904 date system, the date is stored as the number of days since 1 January 1904 (day 1 is 2 January 1904), and there is no leap year problem. The maximum supported date for calculation is 31 December 9999.

Years 29,228 and 30,828

In the C# programming language, the DateTime structure stores absolute timestamps as the number of 100-nanosecond intervals, known as "ticks", since midnight UTC on 1 January 1 AD in the proleptic Gregorian calendar, which will overflow on 14 September 29,228 at 02:48:05.4775808 UTC. Many of Microsoft's applications and services have 100-nanosecond resolution for timekeeping, which will all face similar issues, such as Power Automate's TIME data type and the TimeSpan parameter in various Windows PowerShell commands.

Similarly, in Windows operating systems, the FILETIME structure stores the number of 100-nanosecond ticks since 1 January 1601 as a signed 64-bit integer. This value will overflow on 14 September 30,828 at 02:48:05 UTC, after which Windows will not accept dates beyond this day and will display "invalid system time" errors in NTFS.

Years 32,768 and 65,536

Programs that process years as 16-bit values may encounter problems dealing with either the year 32,768 or 65,536, depending on whether the value is treated as a signed or unsigned integer.

For the year 32,768 problem, years after 32,767 may be interpreted as negative numbers, beginning with −32,768 which may be displayed as 32,768 BC. The year 65,536 problem is more likely to manifest itself by the year 65,536 showing up as year 0.

Year 33,658

Static library archives built by the ar Unix command store timestamps as an ASCII string containing a decimal number of seconds past the Unix epoch (1 January 1970, 00:00:00 UTC), with a limit of 12 ASCII characters. This value will roll over on 01:46:40 UTC on 27 September 33658.

Year 100,000

The year 100,000 will be the first Gregorian year with six digits.

Year 275,760

JavaScript's Date API stores dates as the number of milliseconds since 1 January 1970. Dates have a range of ±100,000,000 days from the epoch, meaning that programs written in JavaScript using the Date API cannot store dates past 13 September, AD 275,760.

Year 292,277,026,596

Systems that store Unix time in seconds using signed 64-bit integers will theoretically be able to represent dates and times up until 15:30:08 UTC on Sunday, 4 December, AD 292,277,026,596. This year is so far in the future (well beyond the likely lifespan of the Earth, the Sun, humanity, and even past some predictions of the lifetime of the universe) that it is mainly referenced as a matter of theoretical interest, joke, or an indication that earlier versions like the year 2038 problem cannot be truly "solved" forever.

Relative time overflow

Microsoft

In Microsoft Windows 7, Windows Server 2003, Windows Server 2008, and Windows Vista, TCP connection start information was stored in hundredths of a second, using a 32-bit unsigned integer, which caused TCP connections to fail after 497 days.

Microsoft Windows 95 and Windows 98 had a problem with rollovers in a virtual device driver, VTDAPI.VXD, which used unsigned 32-bit integers to measure system runtime in milliseconds; this value would overflow after 49.7 days, causing systems to freeze.

Until version 6.0, Microsoft's .NET platform had a bug that caused threadpool hill-climbing to fail periodically after 49.7 days due to an overflow while handling milliseconds since startup.

Boeing

The Boeing 787 aircraft has had at least two software issues related to time storage. In 2015, an error was reported where system runtime was stored in hundredths of a second, using a signed 32-bit integer; this value would overflow after 248 days, after which the onboard generator control systems would crash, causing the aircraft to lose power.

In 2020, the Federal Aviation Administration issued an airworthiness directive requiring 787 operators to power their aircraft down completely before reaching 51 days of uptime, since otherwise systems will begin to display misleading data.

Arduino

The Arduino platform provides relative time via the millis() function. This function returns an unsigned 32-bit integer representing "milliseconds since startup", which will roll over every 49 days. By default, this is the only timing source available in the platform and programs need to take special care to handle rollovers. Internally, millis() is based on counting timer interrupts. Certain powersave modes disable interrupts and therefore stop the counter from advancing during sleep.

Historic year problems

Also for historic years there might be problems when handling historic events, for example:

See also

References

  1. Hoey, Dan (11 December 1985). "Software alert: DATE-86". ARPANET-BBOARDS@MIT-MC.ARPA (Mailing list) (published 14 December 1985). Reproduced in: Austein, Rob (30 January 1987). Neumann, Peter G. (ed.). "DATE-86, or The Ghost of Tinkles Past". The RISKS Digest. 4 (45). Forum on Risks to the Public in Computers and Related Systems, ACM Committee on Computers and Public Policy (published 2 February 1987). Retrieved 29 December 2014.
  2. Davison, Andrew (28 May 2021). "Jan. 4th : TOPS-10 Dating Woes: Jan. 4, 1975" (PDF). A Year of 379 Computer Days. Retrieved 11 October 2024.
  3. Shoppa, Tim (7 November 1998). "What was the TOPS-10 DATE75 fix?". Newsgroupalt.sys.pdp10. Usenet: 36444B15...@trailing-edge.com. Retrieved 11 October 2024 – via Google Groups.
  4. Werme, Ric (13 January 2021) . "DATE75, PDP-10, TULIP, and C". Computer folklore. Werme Family Home Page. Retrieved 11 October 2024.
  5. ^ "Critical and Significant Dates". people.cs.nycu.edu.tw. Retrieved 12 February 2024.
  6. "Directory of linctape-images/os8l/ps-8-system-25.linc". OS/8 can only store dates for an 8 year period...
  7. "The Digital Equipment Corporation PDP-8 : Frequently Asked Questions". COS-310, DEC's commercial operating system for the PDP-8 ... file system is almost the same as OS/8, but dates are recorded differently
  8. ^ "News Notes". InterAction Magazine. Vol. VI, no. 3. Sierra Entertainment. 1993. p. 12.
  9. "Sierra's Macintosh Timebomb". www.benshoof.org. Retrieved 9 March 2023.
  10. "Latest News on the Date Bug".
  11. ^ Janis L. Gogan (9 August 1999). "Applications to the Nines". InformationWeek. Archived from the original on 3 October 2008. Retrieved 21 January 2008.
  12. ^ "GPS week roll over April 6th". cyber.gov.au. Archived from the original on 20 October 2019. Retrieved 10 June 2019.
  13. "GPS Week Number Rollover - April 2019". GPS.gov. National Coordination Office for Space-Based Positioning, Navigation, and Timing. 6 April 2019. Retrieved 25 February 2023.
  14. Manjoo, Farhad. "Unix Tick Tocks to a Billion". Wired. Retrieved 29 March 2022.
  15. "Bank of Queensland hit by "Y2.01k" glitch". 4 January 2010. Retrieved 25 February 2023.
  16. Fried, Ina (5 January 2010). "Windows Mobile glitch dates 2010 texts 2016". CNET. Retrieved 24 February 2023.
  17. "Windows Mobile phones suffer Y2K+10 bug". 4 January 2010. Archived from the original on 23 October 2013. Retrieved 3 July 2013.
  18. "Bank of Queensland vs Y2K – an update". 4 January 2010. Archived from the original on 8 January 2010. Retrieved 3 July 2013.
  19. Loftus, Jack (28 February 2010). "Error: 8001050F Takes Down PlayStation Network". Gizmodo.
  20. Metrowebukmetro (2 March 2010). "Sony fixes PS3 'leap year' bug". Metro. Retrieved 25 October 2022.
  21. "Bug de l'an 2010 en Allemagne: plus de 20 millions de cartes bancaires inutilisables" [2010 Bug in Germany: more than 20 million unusable bank cards]. RTL Belgium (in French). 5 January 2010. Retrieved 25 February 2023.
  22. "Taiwan's Y1C problem". Pinyin News. 2 January 2006.
  23. "NASA's Deep Space Comet Hunter Mission Comes to an End". Jet Propulsion Laboratory. 20 September 2013. Archived from the original on 14 October 2013. Retrieved 9 July 2022.
  24. Mansoor, Saqib (1 January 2020). "WWE 2K20 Refuses To Run In 2020". SegmentNext. Retrieved 1 January 2020.
  25. "Star Wars Jedi: Fallen Order and WWE 2K20 are not launching due to a "2020" bug [UPDATE]". DSOGaming. 1 January 2020. Retrieved 19 November 2020.
  26. "sql – ODBC Connection / Crystal Reports". Stack Overflow. Retrieved 19 November 2020.
  27. "Parking Meters Across NYC Not Accepting Credit Cards, Were Never Programmed To Work In 2020". 2 January 2020. Retrieved 19 November 2020.
  28. "Y2K20 Parking Meter Software Glitch Causes Citywide SNAFU – Gothamist". Archived from the original on 4 January 2020. Retrieved 4 January 2020.
  29. Pallus, Patryk (3 January 2020). "Wielka awaria drukarek fiskalnych. Producent naprawia urządzenia, firmy liczą straty". Business Insider (in Polish). Retrieved 4 January 2020.
  30. "Suunto Spartan Software updates".
  31. "Technical Note TN1049 Approaching the Millennium: The Mac and the Year 2000". Archived from the original on 13 November 2014. Retrieved 20 January 2020.
  32. "Vintage Mac 2020 fixes". Retrieved 21 January 2020.
  33. "Q192201: XCLN: Schedule + 1.0 Will Not Run After 12/31/2019". KnowledgeBase Archive. Retrieved 6 July 2022.
  34. Jeong, Eugene (13 January 2021). "Users report an interesting glitch in Samsung's One UI 3.0, but it has an easy fix". Phone Arena. Retrieved 9 March 2023.
  35. Bhardwaj, Deveshwar (21 May 2021). "Samsung One UI 3.0/3.1 (Android 11) update bug tracker [Cont. updated]". PiunikaWeb. Retrieved 9 March 2023.
  36. Born, Günter (1 January 2022). "Exchange Year 2022 Problem: FIP-FS Scan Engine failed to load – Can't Convert "2201010001" to long (2022/01/01 00:00 UTC)". Born's Tech and Windows World. Retrieved 1 January 2022.
  37. Martin, Alexander (2 January 2022). "Remember the Y2K bug? Microsoft confirms new Y2K22 issue". Sky News.
  38. "Honda Clocks Are Stuck 20 Years in the Past And There Isn't A Fix". Jalopnik. 6 January 2022. Retrieved 8 January 2022.
  39. "Shoddy coding has some Honda cars stuck in the year 2002". Engadget. 7 January 2022. Retrieved 8 January 2022.
  40. Acoba, Paulo (17 August 2022). "Honda & Acura owners with clock problems report, as of August 17, their time is self-correcting but many are still stuck with the wrong date". Archived from the original on 30 May 2023.
  41. 'Leap year glitch' shuts some New Zealand fuel pumps Reuters
  42. "Final Fantasy Game Broken Due To Leap Day". Kotaku. 29 February 2024. Retrieved 10 October 2024.
  43. Yin-Poole, Wesley (29 February 2024). "Theatrhythm Final Fantasy on Nintendo Switch Doesn't Work Today, Feb. 29, Seemingly Because It's a Leap Year". IGN Middle East. Retrieved 10 October 2024.
  44. Dinsdale, Ryan (29 February 2024). "EA Sports WRC Crashing on Start-Up Today, Feb. 29, Because 2024's a Leap Year". IGN Middle East. Retrieved 10 October 2024.
  45. "CRITICAL ALERT: Mail not routing after Domino restarts beginning December 13, 2024 - Customer Support". support.hcl-software.com. Retrieved 19 December 2024.
  46. "Big tech warns of 'Japan's millennium bug' ahead of Akihito's abdication". The Guardian. 25 July 2018.
  47. AGENCIAS, RTVE es / (1 January 2025). "Los trenes Avril que unen Madrid con Galicia y Asturias, parados por un fallo informático". RTVE.es (in Spanish). Retrieved 1 January 2025.
  48. "Una avería en los cargadores de las baterías de los trenes Avril deja inoperativas todas las unidades". La Voz de Galicia (in Spanish). 1 January 2025. Retrieved 1 January 2025.
  49. "Los trenes Avril recuperan su normal funcionamiento tras solucionar el problema informático de los cargadores de baterías". Talgo press release (in Spanish). 2 January 2025. Retrieved 4 January 2025.
  50. "Years since 1900 + seven bits = breakage in 2028". rachelbythebay.com.
  51. "MPE/iX Release 7.5 Patch Revision 2028 – Beechglen Development Inc".
  52. "Palm OS® Protein C/C++ Compiler Language & Library Reference" (PDF). Retrieved 12 October 2019.
  53. "subject:RE: Date limited to 2031". mail-archive.com. Retrieved 12 October 2019.
  54. David L. Mills (12 May 2012). "The NTP Era and Era Numbering". Retrieved 24 September 2016.
  55. W. Richard Stevens; Bill Fenner; Andrew M. Rudoff (2004). UNIX Network Programming. Addison-Wesley Professional. pp. 582–. ISBN 978-0-13-141155-5.
  56. "gmtime, _gmtime32, _gmtime64". Microsoft. Retrieved 8 April 2022.
  57. "Oracle Access Manager". Oracle Communities. Oracle Corporation. 24 March 2022. Retrieved 25 February 2023.
  58. Apple Computer, Inc., Inside Macintosh, Volume II, Addison Wesley, 1985, p. 369
  59. "ProDOS Dates -- 2000 and Beyond". Apple, Inc. Retrieved 6 December 2019.
  60. "ProDOS 2.5". Retrieved 9 June 2021.
  61. ^ Lascu, Octavian; Eckam, Hans-Peter; Kozakos, George; Pereira, Paulo Vitor (June 2013), Server Time Protocol Planning Guide, IBM Redbooks (4th ed.), IBM, p. 19, ISBN 978-0738438108, retrieved 11 August 2019
  62. "SAP note 2258792 (access to SAP Support Portal required)". 30 November 2018.
  63. "strptime - The Open Group Base Specifications Issue 7, 2018 edition". Retrieved 4 March 2023.
  64. "DS3231 - Extremely Accurate I²C-Integrated RTC/TCXO/Crystal".
  65. Robertson, Alan (4 December 2009) . "OS_Word 14,3 (SWI &07)". RISC OS Open Instiki. Archived from the original on 29 November 2023. Retrieved 1 October 2024.
  66. "time package – time". pkg.go.dev.
  67. "Time series / date functionality — pandas 2.2.3 documentation". pandas.pydata.org.
  68. "std::chrono::duration". en.cppreference.com.
  69. "Update version for v5.0.0 release". Archived from the original on 21 January 2021. Retrieved 19 June 2021.
  70. "ext4: Fix handling of extended tv_sec - kernel/git/stable/linux.git - Linux kernel stable tree". git.kernel.org.
  71. "Ext4 Disk Layout - Ext4". ext4.wiki.kernel.org.
  72. Herschel, John (1849). Outlines of Astronomy. p. 629.
  73. Steel, Duncan (2000). Marking Time: The Epic Quest to Invent the Perfect Calendar. John Wiley & Sons. p. 185. ISBN 978-0-471-29827-4.
  74. Chris Hemedinger (5 April 2010). "In the year 9999..."
  75. "Microsoft Access Database Files". SAS 9.4 and SAS® Viya® 3.5 Programming Documentation. The Conversion of Date and Time Values between SAS Data Sets and Microsoft Access Database.
  76. "OlMarkInterval enumeration (Outlook)". 30 March 2022.
  77. "Filtering Items Using Query Keywords". 22 January 2022.
  78. "Differences between the 1900 and the 1904 date system – Office". Microsoft. 5 May 2022. Retrieved 22 February 2023.
  79. "Excel specifications and limits". Microsoft Support. Retrieved 22 February 2023.
  80. "DateTime Struct (System)". learn.microsoft.com. Retrieved 10 October 2024.
  81. "Working around accounts that expire with AAD Connect: REDUX". www.undocumented-features.com.
  82. "List of data types for custom metrics". learn.microsoft.com. 18 July 2023. Retrieved 12 February 2024.
  83. "Search-ADAccount". learn.microsoft.com. Retrieved 12 February 2024.
  84. Thulin, Anders (6 April 2013). "Interpretation of NTFS Timestamps". Forensic Focus. Retrieved 23 July 2019.
  85. "Top 10 Fun Reasons why you Should Stop Using Delphi, now!". Archived from the original on 23 January 2008. Retrieved 21 January 2008.
  86. "Folio TechNote". Archived from the original on 9 February 2008. Retrieved 21 January 2008.
  87. "Date – Javascript". MDN. Retrieved 5 July 2022.
  88. William Porquet (15 August 2007). "Project 2038 FAQ". Retrieved 5 March 2010.
  89. "Date/Time Conversion Contract Language" (PDF). Office of Information Technology Services, New York. 23 November 2021. Retrieved 25 February 2023.
  90. "All the TCP/IP ports that are in a TIME_WAIT status are not closed after 497 days from system startup in Windows Vista, in Windows 7, in Windows Server 2008 and in Windows Server 2008 R2 - Microsoft Support". support.microsoft.com.
  91. "Computer Hangs After 49.7 Days". 8 May 1999. Archived from the original on 8 May 1999.
  92. "Hysteresis effect on threadpool hill-climbing · Issue #51935 · dotnet/runtime". GitHub. Retrieved 25 February 2024.
  93. Edgar Alvarez (1 May 2015). "To keep a Boeing Dreamliner flying, reboot once every 248 days". Engadget. Retrieved 2 April 2020.
  94. "Airworthiness Directives; The Boeing Company Airplanes". Federal Register. May 2015.
  95. Gareth Corfield (2 April 2020). "Boeing 787s must be turned off and on every 51 days to prevent 'misleading data' being shown to pilots". The Register. Retrieved 2 April 2020.
  96. "The Answer to the Arduino millis() Overflow/Wraparound Question". EEWeb. 22 March 2018.
  97. "How to keep track of millis during sleep mode". Arduino Stack Exchange.
Year-related problems
Decimal or BCD storage related
Binary storage related
Hexadecimal storage related
Categories: