Time formatting and storage bugs: Difference between revisions

In [[computer science]], [[data type]] limitations and [[software bugs]] can cause errors in [[system time|time and date]] calculation or display. These are most commonly manifestations of [[arithmetic overflow]], but can also be the result of other issues. The most well-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.

 

On 4 January 1975, the 12-bit field that had been used for dates in the [[PDP-10|DECsystem-10]] 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>

 

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.<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 [[Commercial Operating System|COS-310]] 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>

 

Multiple [[Sierra Entertainment]] games released for the [[Classic Mac OS]] started to [[Hang (computing)|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 [[#Year 2040|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 [[#Year 2007|almost 14 years]].<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=[[Sierra Entertainment]]}}</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>

 

The [[Domain/OS]] 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 the last few months before the year 2000, two other date-related milestones occurred that received less publicity than the then-impending Y2K problem.

 

{{main|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 (computing)|epoch]]), 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=[[InformationWeek]]|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 [[UTC]] 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=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 weeks (157 years), and will not return to zero until the year 2137.<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>

 

{{See also|Magic number (programming)|Magic string}}

 

{{main|Year 2000 problem}}

{{See also|Year 1900 problem}}

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 [[Centenarian|people over 100 years old]].

 

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 "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>

 

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|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 [[#Year 2040|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.<ref name="Sierra"/>

 

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 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>

 

{{main|Year 2011 problem}}

[[Taiwan]] officially uses the [[Minguo calendar]], which considers the [[Gregorian calendar|Gregorian]] 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>

 

 

In 2019, the [[GPS week number rollover#2019 occurrence|second GPS week number rollover]] occurred.

 

{{main|Japanese calendar era bug}}

On 30 April 2019, Emperor [[Akihito]] of Japan [[2019 Japanese imperial transition|abdicated]] in favor of his son [[Naruhito]]. As years in Japan are traditionally referred to by [[Japanese era name|era name]]s that correspond to the reign of each emperor, this resulted in a new era name, {{nihongo|[[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.

 

The video games ''[[WWE 2K20]]'' and ''[[Star Wars Jedi: Fallen Order]]'' both [[Crash (computing)|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.<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 [UPDATE]|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, [[Crystal Reports|Crystal Reports 8.5]] 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>

 

[[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.<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>

 

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 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.<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>

 

Samsung users reported that phones running on the latest [[One UI|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.<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 [Cont. updated] |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>

 

 

[[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.<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>

 

Payment card readers at petrol pumps in New Zealand were [[Leap year problem|unable to handle the leap year]] and were unable to properly dispense gasoline.<ref>[https://www.reuters.com/world/asia-pacific/leap-year-glitch-shuts-some-new-zealand-fuel-pumps-2024-02-29/ 'Leap year glitch' shuts some New Zealand fuel pumps] Reuters</ref>

 

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.<ref>[https://kotaku.com/final-fantasy-theatrhythm-broken-wrc-leap-day-bug-ps4-1851298039 Final Fantasy Game Broken Due To Leap Day] Kotaku</ref><ref>[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 Theatrhythm Final Fantasy on Nintendo Switch Doesn’t Work Today, Feb. 29, Seemingly Because It’s a Leap Year] IGN</ref><ref>[https://me.ign.com/en/ps5/218621/news/ea-sports-wrc-crashing-on-start-up-today-feb-29-because-2024s-a-leap-year EA Sports WRC Crashing on Start-Up Today, Feb. 29, Because 2024's a Leap Year] IGN</ref>

 

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.<ref>{{cite web|title=Big tech warns of 'Japan's millennium bug' ahead of Akihito's abdication|website=[[The Guardian]]|date=25 July 2018|url=https://www.theguardian.com/technology/2018/jul/25/big-tech-warns-japan-millennium-bug-y2k-emperor-akihito-abdication}}</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 [[Signedness|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.<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 [[HP 3000]], 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>

 

 

{{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{{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>

 

{{main|Year 2038 problem}}

 

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 [[Oracle Corporation|Oracle's]] Access Manager version 10.1.4.3 for Windows. The Identity Console component sets a cookie containing [[User interface|UI]] preferences with an expiry of 500,000,000 seconds in the future (about 16 years). This is beyond 19 January 2038 and so it throws an [[Exception handling|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.<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 April 2022.

 

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

 

Early Apple [[Macintosh]] computers store time in their [[real-time clock]]s (RTCs) and [[Hierarchical File System (Apple)|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³²&minus;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, [[HFS Plus|HFS+]], the default format for all of Apple's recent Macintosh 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.<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>

 

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.<ref name=Lascu>{{Citation|title=Server Time Protocol Planning Guide|edition=4th|url=http://www.redbooks.ibm.com/abstracts/sg247280.html|publisher=[[IBM]]|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>

 

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.

 

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). 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 [[Single UNIX Specification]] for parsing two-digit years using [[strptime|{{code|strptime()}}]], "values in the range [69,99] shall refer to years 1969 to 1999 inclusive and values in the range [00,68] shall refer to years 2000 to 2068 inclusive",<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.

 

Programs that store dates as the number of days since an arbitrary date (or ''[[Epoch (computing)|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{{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 [[Arithmetic overflow|overflow]] 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>

 

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.{{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 [[epoch of 1980-01-01]].

 

{{Unreferenced section|date=August 2021}}

[[DOS]] and [[Microsoft Windows|Windows]] file date [[API function|API]] and conversion functions (such as [[DOS API|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.

 

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.

 

 

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

 

 

This will also affect the [[ZIP (file format)|ZIP archive file format]], as it uses FAT file modification timestamps internally.

 

{{main|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 (computing)|epoch]]), 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/>

 

 

Some timekeeping systems count [[nanoseconds]] since 1970 using a 64-bit signed integer, which will overflow at 11 April 2262, 23:47:16. The [[Go (programming language)|Go programming language's]] {{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 [[pandas (software)|pandas]],<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> [[C++]] chrono::nanoseconds,<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 [[QEMU]] 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>

 

 

In [[ext4]], 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>[https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=a4dad1ae24f850410c4e60f22823cba1289b8d52 ext4: Fix handling of extended tv_sec]</ref>

Within this "extra" 32-bit field, the lower two bits are used to extend the 32-bit seconds field to be 34 bit wide; the upper 30 bits are used to provide nanosecond timestamp accuracy. Therefore, timestamps should not overflow until May 2446.<ref>[https://ext4.wiki.kernel.org/index.php/Ext4_Disk_Layout#Inode_Timestamps Ext4 Disk Layout: Inode Timestamps]</ref>

 

On time scales of thousands of years, the Gregorian calendar falls behind the astronomical seasons. This is because [[Earth's rotation#Changes|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 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>

 

 

[[Microsoft Outlook]] 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)|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>

 

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.

 

 

 

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>{{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> 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>

 

 

 

 

 

 

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>

 

 

[[.NET]] up to version 6.0 had a bug that caused threadpool hill-climbing to fail periodically after 49.7 days due to an overflow while handling the 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>

 

The [[Boeing 787]] 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=[[Engadget]]|date=1 May 2015|access-date=2 April 2020}}</ref>

 

In 2020, the [[FAA]] 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=[[The Register]]|date=2 April 2020|access-date=2 April 2020}}</ref>

 

The [[Arduino]] 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>

 

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

* [[Year zero|Year zero problem]]

* [[Year 1900 problem]]

 

* [[Software bug]]

* [[Heisenbug]]

* [[Long Now Foundation]]

 

{{Reflist}}