Year 10,000 problem: Difference between revisions
←Removed redirect to Time formatting and storage bugs#Year 10,000 Tags: Removed redirect Manual revert Reverted Visual edit Mobile edit Mobile web edit |
|||
| Line 1: | Line 1: | ||
{{Afd-merge to|Time formatting and storage bugs|Year 10,000 problem (5th nomination)|23 October 2020}} |
|||
{{short description|Potential future technological problem}} |
|||
{{Redirect category shell| |
|||
{{Original research|date=February 2011}} |
|||
{{R from merge}} |
|||
The '''year 10,000 problem''' (also known as the '''Y10K problem''' or the '''deca-millennium bug''')<ref>{{cite web|url=http://www.longnow.org/about/|title=About - The Long Now|author=The Long Now Foundation|accessdate=28 February 2010}}</ref> is the class of all potential [[time formatting and storage bugs]] that would emerge when the need to express years with five digits arises. The actual problem cannot have major, discernible effects today, but is also sometimes mentioned for humorous purposes. |
|||
}} |
|||
Five-digit years are already a problem today for many forward-looking analysis, niche programs (e.g. software that examines proposals for the [[Radioactive_waste#Long_term_management|long-term handling of nuclear waste]]).{{Citation needed|date=April 2020}} |
|||
==Examples== |
|||
This problem can be seen in the spreadsheet program [[Microsoft Excel]] through at least its [[Office 2013]] release, which stores dates as the number of days since 31 December 1899 (day 1 is 1900-01-01) with a [[Microsoft_Excel#Fictional_leap_day_in_the_year_1900|fictional leap day in 1900]]; similarly, [[Microsoft Access]] stores dates as the number of days since 30 December 1899 (day 1 is 1899-12-31). In either application, a date value of 2958465 will be correctly formatted as "31 December 9999", but adding 1 to that to step over to the expected date of "1 January 10000" will cause a formatting error; in Excel, for example, it will be displayed in the cell as a series of ''#'' characters. Excel also cannot automatically convert date-formatted strings such as "12/12/2007" to dates if the year exceeds 9999; "12/12/9999" is automatically converted to a date when entered into a cell, but "12/12/10000" is not. The [[Long Now Foundation]] ran into this limitation of Excel during the design of the [[Clock of the Long Now|10,000 year clock]].<ref>{{cite news|title=Lessons from the Long Now|url=http://media.longnow.org/djlongnow_media/press/pdf/0200001-Smith-LessonsfromtheLongNow.org.pdf|work=Software Development Magazine|author=Roger Smith}}</ref> |
|||
In [[Microsoft SQL Server]], the [[Transact-SQL]] API has a "datetime" type which cannot store dates past 31 December 9999. The first date is January 1, 1753. Attempting to create new datetime values past the year 9999 will result in an out-of-range error.<ref>{{cite web|url=https://docs.microsoft.com/en-us/sql/t-sql/data-types/datetime-transact-sql?view=sql-server-ver15|title=datetime (Transact-SQL)|accessdate=11 June 2020}}</ref> |
|||
[[SAP NetWeaver]] handles date variables as strings of 8 characters (YYYYMMDD).<ref>{{cite web|url=https://help.sap.com/saphelp_nw70/helpdata/en/fc/eb2fd9358411d1829f0000e829fbfe/content.htm|title=Predefined ABAP Types|author=SAP AG|accessdate=24 April 2015}}</ref> |
|||
The [[Open-source software|open source]] [[OpenOffice.org Calc]] program is able to display dates beyond the year 9999 correctly with five digit years, but at least through version 2.4 falls victim to the [[Year 32,768 problem]]: "31 December 32,767" is the highest available date it can properly display. 32767, or 2<sup>15</sup> − 1, is the highest positive number that can be represented using a 16-bit signed integer, adding one to this value causes it to [[arithmetic overflow|overflow]], and Calc interprets the year as a large negative number, "1 January −32,768". |
|||
The [[GNU]] [[Fortran]] [[compiler]], [[GNU Compiler Collection|g77]], makes reference in [[Runtime system|runtime]] environment limits to year 10,000 (Y10K) problems when using [[intrinsic function]]s with this compiler suite. The problem is simply stated as, "Most intrinsics returning, or computing values based on, date information are prone to Year-10,000 (Y10K) problems, due to supporting only 4 digits for the year." The failure mode suggested in all of the intrinsic functions is that, "Programs making use of this intrinsic might not be Year 10000 (Y10K) compliant. For example, the date might appear, to such programs, to wrap around (change from a larger value to a smaller one) as of the Year 10000."<ref>{{cite web|url=https://gcc.gnu.org/onlinedocs/gcc-3.4.6/g77/Year-10000-_0028Y10K_0029-Problems.html#Year-10000-_0028Y10K_0029-Problems|title=Year 10000 (Y10K) Problems}}</ref> |
|||
[[Python (programming language)|Python]]'s <code>datetime</code> module explicitly only supports one- to four-digit dates.<ref>{{cite web|url=https://github.com/python/cpython/blob/6f0eb93183519024cb360162bdd81b9faec97ba6/Lib/datetime.py#L14|title=CPython source code for <tt>datetime</tt>|date=2017-06-14}}</ref> Using a date containing a later or earlier year results in a <code>ValueError</code> being raised. |
|||
[[PHP]]'s <code>DateTime</code> class can handle five-digit years, except for parsing date strings with e.g. <code>new DateTime(...)</code>. |
|||
[[Windows NT]] becomes unstable when the Year 10000 is reached. After a restart, the date will be reset to ~1900 or somewhere near that. This was demonstrated by some YouTubers.<ref>{{Cite web|url=https://www.youtube.com/watch?v=QA8vVbSEWN4|title=Y10K-Bug {{!}} A weird experience [Year 10,000 on Windows XP]|last=|first=|date=|website=|url-status=live|archive-url=|archive-date=|access-date=}}</ref><ref>{{Cite web|url=https://www.youtube.com/watch?v=sfklo0LxflU|title=Windows 7 Year 9999 bug|last=|first=|date=|website=|url-status=live|archive-url=|archive-date=|access-date=}}</ref> |
|||
==Problems with data representation== |
|||
Unlike the [[Year 2000 problem]], where significant digits were omitted from the stored values of years, fixing the Year 10,000 problem does not require updating old records (assuming they are already Y2K-compliant), since all four significant digits are present. It only requires that record storage in decimal be able to store five or more digits. |
|||
There is, however, a potential problem with record sets that make use of [[lexicographical order|lexical sorting]]. For example, representations of dates in the range 10,000–19,999 would appear interlaced with dates in the range 1000–1999 rather than after the year 9999. |
|||
===Mitigation=== |
|||
The [[Long Now Foundation]] is attempting to foster the custom of writing years with five digits, so that the year {{CURRENTYEAR}} would be written as "0{{CURRENTYEAR}}". This would preempt the Year 10,000 problem, but would in turn be susceptible to the "Year 100,000 problem". |
|||
The Internet [[Kermit (protocol)|Kermit]] Service [[Daemon (computer software)|Daemon]] (IKSD) uses a five-digit field for the year in the Database Record Format: "Date-time fields are right-adjusted within a field of 18 with the leading blank reserved for Y10K".<ref>{{cite web|url= http://www.columbia.edu/kermit/ftp/c-kermit/iksd.txt|title=IKSD – The Internet Kermit Service Daemon|publisher=Columbia University|date=12 December 2001}}</ref> |
|||
[[ISO 8601]] specifies that years be written with four digits, but allows for extension to five or more digits, with prior agreement between the parties exchanging the information. |
|||
==See also== |
|||
*[[Year 2000 problem]] |
|||
*[[Holocene calendar]] |
|||
*[[Perpetual calendar]] |
|||
*[[System time]] |
|||
*[[Year 2038 problem]] |
|||
==References== |
|||
{{reflist}} |
|||
==Further reading== |
|||
*{{cite web|title=The Y10K Problem, Pascal's Wager, and Petersberg|url=http://www.mathpages.com/home/kmath200.htm|work=MathPages: Probability and Statistics}} — MathPages notes a similarity between the Y10K problem and both [[Pascal's wager]] and the [[St. Petersburg paradox]], stating that the cost of fixing the various Y10K, Y100K, and successive problems is increased in direct proportion to the remoteness of the date, and that therefore each problem should in fact be given equal weight. |
|||
*{{cite web|url=http://www.templetons.com/brad/y10k.html|title=Computer systems worry over pending "year 10,000" problem|author=[[Brad Templeton]]}} — Templeton hypothesizes the impact of the Year 10000 problem. |
|||
*{{cite web|url=http://www.stsc.hill.af.mil/crosstalk/1996/11/xt96d11k.asp|title=The Year 10,000 Problem: It's Not Too Late to Start|author=Lorin May}} |
|||
*{{cite news|title=Beyond Year 2000 Compliance: Year 10,000 Compliance|url=http://www.recapinc.com/aprecap_S97_year10000.htm|work=A/P Recap|author=}} |
|||
==External links== |
|||
* {{Spoken Wikipedia|En-Year_10,000_Problem-article.ogg|2017-09-10}} |
|||
{{Year-related problems}} |
|||
{{Doomsday}} |
|||
{{DEFAULTSORT:Year 10000 problem}} |
|||
[[Category:Time formatting and storage bugs]] |
|||
[[Category:Calendars]] |
|||
[[Category:Future problems]] |
|||
[[Category:10th millennium|Problem]] |
|||
Revision as of 13:53, 3 November 2024
 | This article was nominated for deletion. The discussion was closed on 23 October 2020 with a consensus to merge the content into the article Time formatting and storage bugs. If you find that such action has not been taken promptly, please consider assisting in the merger instead of re-nominating the article for deletion. To discuss the merger, please use the destination article's talk page. (October 2020) |
 | This article possibly contains original research. (February 2011) |
The year 10,000 problem (also known as the Y10K problem or the deca-millennium bug)[1] is the class of all potential time formatting and storage bugs that would emerge when the need to express years with five digits arises. The actual problem cannot have major, discernible effects today, but is also sometimes mentioned for humorous purposes. Five-digit years are already a problem today for many forward-looking analysis, niche programs (e.g. software that examines proposals for the long-term handling of nuclear waste).[citation needed]
Examples
This problem can be seen in the spreadsheet program Microsoft Excel through at least its Office 2013 release, which stores dates as the number of days since 31 December 1899 (day 1 is 1900-01-01) with a fictional leap day in 1900; similarly, Microsoft Access stores dates as the number of days since 30 December 1899 (day 1 is 1899-12-31). In either application, a date value of 2958465 will be correctly formatted as "31 December 9999", but adding 1 to that to step over to the expected date of "1 January 10000" will cause a formatting error; in Excel, for example, it will be displayed in the cell as a series of # characters. Excel also cannot automatically convert date-formatted strings such as "12/12/2007" to dates if the year exceeds 9999; "12/12/9999" is automatically converted to a date when entered into a cell, but "12/12/10000" is not. The Long Now Foundation ran into this limitation of Excel during the design of the 10,000 year clock.[2]
In Microsoft SQL Server, the Transact-SQL API has a "datetime" type which cannot store dates past 31 December 9999. The first date is January 1, 1753. Attempting to create new datetime values past the year 9999 will result in an out-of-range error.[3]
SAP NetWeaver handles date variables as strings of 8 characters (YYYYMMDD).[4]
The open source OpenOffice.org Calc program is able to display dates beyond the year 9999 correctly with five digit years, but at least through version 2.4 falls victim to the Year 32,768 problem: "31 December 32,767" is the highest available date it can properly display. 32767, or 215 − 1, is the highest positive number that can be represented using a 16-bit signed integer, adding one to this value causes it to overflow, and Calc interprets the year as a large negative number, "1 January −32,768".
The GNU Fortran compiler, g77, makes reference in runtime environment limits to year 10,000 (Y10K) problems when using intrinsic functions with this compiler suite. The problem is simply stated as, "Most intrinsics returning, or computing values based on, date information are prone to Year-10,000 (Y10K) problems, due to supporting only 4 digits for the year." The failure mode suggested in all of the intrinsic functions is that, "Programs making use of this intrinsic might not be Year 10000 (Y10K) compliant. For example, the date might appear, to such programs, to wrap around (change from a larger value to a smaller one) as of the Year 10000."[5]
Python's datetime module explicitly only supports one- to four-digit dates.[6] Using a date containing a later or earlier year results in a ValueError being raised.
PHP's DateTime class can handle five-digit years, except for parsing date strings with e.g. new DateTime(...).
Windows NT becomes unstable when the Year 10000 is reached. After a restart, the date will be reset to ~1900 or somewhere near that. This was demonstrated by some YouTubers.[7][8]
Problems with data representation
Unlike the Year 2000 problem, where significant digits were omitted from the stored values of years, fixing the Year 10,000 problem does not require updating old records (assuming they are already Y2K-compliant), since all four significant digits are present. It only requires that record storage in decimal be able to store five or more digits.
There is, however, a potential problem with record sets that make use of lexical sorting. For example, representations of dates in the range 10,000–19,999 would appear interlaced with dates in the range 1000–1999 rather than after the year 9999.
Mitigation
The Long Now Foundation is attempting to foster the custom of writing years with five digits, so that the year 2024 would be written as "02024". This would preempt the Year 10,000 problem, but would in turn be susceptible to the "Year 100,000 problem".
The Internet Kermit Service Daemon (IKSD) uses a five-digit field for the year in the Database Record Format: "Date-time fields are right-adjusted within a field of 18 with the leading blank reserved for Y10K".[9]
ISO 8601 specifies that years be written with four digits, but allows for extension to five or more digits, with prior agreement between the parties exchanging the information.
See also
References
- ^ The Long Now Foundation. "About - The Long Now". Retrieved 28 February 2010.
- ^ Roger Smith. "Lessons from the Long Now" (PDF). Software Development Magazine.
- ^ "datetime (Transact-SQL)". Retrieved 11 June 2020.
- ^ SAP AG. "Predefined ABAP Types". Retrieved 24 April 2015.
- ^ "Year 10000 (Y10K) Problems".
- ^ "CPython source code for datetime". 2017-06-14.
- ^ "Y10K-Bug | A weird experience [Year 10,000 on Windows XP]".
{{cite web}}: CS1 maint: url-status (link) - ^ "Windows 7 Year 9999 bug".
{{cite web}}: CS1 maint: url-status (link) - ^ "IKSD – The Internet Kermit Service Daemon". Columbia University. 12 December 2001.
Further reading
- "The Y10K Problem, Pascal's Wager, and Petersberg". MathPages: Probability and Statistics. — MathPages notes a similarity between the Y10K problem and both Pascal's wager and the St. Petersburg paradox, stating that the cost of fixing the various Y10K, Y100K, and successive problems is increased in direct proportion to the remoteness of the date, and that therefore each problem should in fact be given equal weight.
- Brad Templeton. "Computer systems worry over pending "year 10,000" problem". — Templeton hypothesizes the impact of the Year 10000 problem.
- Lorin May. "The Year 10,000 Problem: It's Not Too Late to Start".
- "Beyond Year 2000 Compliance: Year 10,000 Compliance". A/P Recap.
External links
