Talk:Year 10,000 problem

Page contents not supported in other languages.
From Wikipedia, the free encyclopedia

Talk page archive 1: 2004–2007


Consolidate far-future pages[edit]

I think the year 10,000 and beyond deserve an entry; they elicit thought about interesting computer science issues including planning for unlikely occurrences and designing for bug-resistance. I do think, however, that the page should be named (and include) "Year 10,000 problem and beyond". It can include interesting factoids of the sort interesting to info-holics such as "how many leap seconds will there have been by the time we face the year 10,000 problem? 100,000?". Inquiring minds want to know! —Preceding unsigned comment added by Kennita728 (talk • contribs) 07:25, 16 January 2008 (UTC)[reply]

Possible references[edit]

  • "We'll know the shift has happened when programmers begin to anticipate the Year 10000 problem and assign five digits instead of four to year dates." from The Clock of the Long Now: Time and Responsibility
    By Stewart Brand
    Published 1999
    Basic Books
    Time
    190 pages
    ISBN 0465007805.
  • Also a brief mention in Accounting Principles
    By Philip E. Fess, Clifford Rollin Niswonger, Carl S. Warren
  • and in College Accounting
    By John Ellis Price, Horace R. Brock.

(from Google Books search) --Coppertwig (talk) 04:08, 19 January 2008 (UTC)[reply]

No 31/12/1899[edit]

=DATE(0,1,0) gives 0/01/1900 if you -1 from that the cell fills with hash's the same as 31/12/9999 + 1 does -- Stony (talk) 07:22, 29 May 2008 (UTC)[reply]

...in some particular program? --NapoliRoma (talk) 22:22, 31 May 2008 (UTC)[reply]
Oh sorry, MS Excel 2007, was reading something about it before i posted this and just somehow assumed it was about it, must have been a blonde moment. Stony (talk) 05:55, 1 June 2008 (UTC)[reply]

Seriously?[edit]

I know Microsoft are a bit slow at making important updates, but I'm sure even they will have made a few changes to their software upon the release of Microsoft Office 10000. Maybe they'll release a service pack. Who knows. But is this article not a bit of a joke? —Preceding unsigned comment added by Helzagood (talk • contribs) 02:54, 30 August 2008 (UTC)[reply]

Asked and answered in the article itself.--NapoliRoma (talk) 17:04, 30 August 2008 (UTC)[reply]
I think it is a joke, the whole tiem travel thing is proves it as such. —Preceding unsigned comment added by 67.181.110.37 (talk) 04:30, 2 February 2009 (UTC)[reply]
It's not a joke. I'm a computer programmer and it is true that all years are now kept in 4 digits. In the year 10000 we will have problems. And like the article says, computing halflife of nuclear waste runs into this year 10,000 problem. You never know, with medical technology advancing there is some slim hope some of us might be alive by then. But that is pure speculation. — Preceding unsigned comment added by 50.142.35.91 (talk) 20:39, 22 December 2012 (UTC)[reply]
With all due respect, I have seriously doubts about your claim of being a "computer programmer". Firstly. that is not a commonly used term. Those working in the field tend to call themselves "software developers". Second, the claim that "all years are now kept in 4 digits" is flat out wrong. By my estimate, the most common datatypes for storing years are, in order, N/A (entire dates or date/times are stored instead of storing dates separately), variable-length strings, and 16, 32 or 64-bit integers. In particular, if math needs to be done on a date, it is almost always done on a numeric variable, not on a string. --Guy Macon (talk) 21:31, 22 December 2012 (UTC)[reply]
Without commenting on the bigger issue, "computer programmer" seems a fairly common term amongst those of us who have been in the profession for more than a couple of decades. Rwessel (talk) 22:02, 26 December 2012 (UTC)[reply]
Off topic chat

No doubt those who deal with these things professionally, e.g., regarding nuclear materials' respective half-lives, will not need to deal with precise Gregorian calendar years, and will develop other ways of representing time, such as by using dates expressed in hex form, or, more likely, years after a commonly accepted date, or, if going out that far, years after a given date + 10^x years. Historically, humans have periodically just adopted a new calendar, a new year 1. Of course, not everyone uses the Gregorian calendar for everything even now... Xenophonix (talk) 18:27, 30 June 2014 (UTC)[reply]

Example slight innaccuracy[edit]

The example section currently says: 

 This problem can be seen in the spreadsheet program Microsoft Excel through at least the Office Excel 2007 release,
 which stores dates as the number of days since 31 December 1899 (day 1 is 1900-01-01)

This is slightly inaccurate, as Excel 03 and 07 at least (and thus, one can assume that all prior versions) will display a date code of zero as 1/0/1900. So, technically, The above lines could be changed to say "which stores dates as the number of dates since the "Zeroth" day of January, 1900 (Day 1 is 1900-01-01)". I did not make this change, because I am not sure if the obfuscation that would result from it is worth the slight increase in accuracy. Farfromunique (talk) 22:23, 13 February 2009 (UTC)[reply]

There's another problem with that bit of the article, as far as I can see:
... Excel 2007 ... (day 1 is 1900-01-01), ... Microsoft Access ... (day 1 is 1899-12-31). In either application, a date value of 2958465 will be correctly formatted as "31 December 9999"
If day 1 is different in the two programs, how can day 2958465 be the same date? 87.244.97.152 (talk) 13:57, 14 February 2014 (UTC)[reply]
Excel was designed to be compatible with several previously existing spreadsheets. Unfortunately that included reproducing a bug in the date calculations of those packages, namely that they *incorrectly* assumed 1900 was a leap year. So any day number prior to March 1, 1900 is incorrect. Access doesn't have the same bug, but to keep the dates compatible (at least after February 28/29, 1900), they start day 1 in Excel on December 31, 1899 instead of January 1, 1900 like in Access. The problem mostly goes away if you use 1904-based dates instead. Rwessel (talk) 17:33, 14 February 2014 (UTC)[reply]

Current systems will be obsolete?[edit]

The article currently says:[1]

Historical and technological trends suggest that in the actual year 10,000 it is unlikely that any of the data processing technology or software in use today will still be active, or that the present Gregorian calendar system will even still be in use.

I'm sure I heard that in the decades leading up to the year 2000, that problem was foreseen but not dealt with because of the same argument. Brian Jason Drake 11:44, 30 September 2009 (UTC)[reply]

mmm, while qualitatively similar quantitatively there is a huge difference. Afaict people expected these systems to last for a few years or maybe a decade or so and instead they lasted several decades and hit Y2K. In summary systems lasting 10 or so times as long as expected is a real problem that should be considered when developing software that handles dates. Since people don't seem to have learnt thier lesson on this and/or are constrained by interfaces with existing systems it is likely there will be Y2K like events in 2038, 2100 and 2108 and minor ones every few years (some stuff broke in 2010 because of hasty Y2K fixes that weren't sorted out properly later and more will likely break for that reason each decade).
But Y10K is nearly a hundred times further away than these and there is little if any evidence to suggest that software lasting over 7000 years is likely. Plugwash (talk) 14:39, 13 February 2010 (UTC)[reply]
Heck, it's longer than the Universe has existed so far! --NapoliRoma (talk) 20:10, 13 February 2010 (UTC)[reply]
Not according to science, which says that:
  1. the Universe is ~13700000000 years old,
  2. even the Earth is ~4500000000 years old,
  3. life on it is about ~3800000000 to 4200000000 years old,
  4. even animal life is about ~500000000 to 600000000 years old,
  5. even modern humans exist since ~200000 to 300000 years. Alfa-ketosav (talk) 20:41, 28 December 2019 (UTC)[reply]

Going Backwards?[edit]

Well I don't know why I'm discussing this since this is like so far in the future, but why don't we just go backwards after we reach the year 9999? Like the BC period it went backwards until it reached 1BC and then the next year it went to 1AD, 2AD, so on and so on. That will solve all our problems. After 9999 we will go to 9998 —Preceding unsigned comment added by MavsMan27 (talk • contribs) 17:48, 6 April 2010 (UTC)[reply]

Because events two years apart would have the same date for one thing. That might get just slightly confusing. You'd need an additional field, and all the logic to go with it, to specify the period (like BC/AD) at which point you may as well just correct the original mistake and use a bigger number for the year. 87.244.97.152 (talk) 14:26, 14 February 2014 (UTC)[reply]

What about Y100K problem ?[edit]

and Y1M one, how humanity can survive to such a terrible issue ? May be one day one genious will be able to separate human representation from the computer one. May be he will use something like a timestamp to deal with dates which are billion years in the future or in the past. Until that glorious day, many useless articles will pop up. --193.52.225.144 (talk) 09:32, 22 July 2010 (UTC)[reply]

  • As a time traveler, I wish you would take things like this more seriously. Two of my friends died because of improper date stamps on nuclear waste in Nevada. --67.180.240.253 (talk) 19:55, 24 March 13442 (UTC)
  • There is already RFC for this: S. Glassman, M. Manasse, J. Mogul (1 April 1999). Y10K and Beyond. RFC 2550. .

It's decent work, but I admit dates before year 0 are bit crude, still as stated in RFC there is many many more dates after the year 0 than before so I think it's acceptable. --82.130.29.157 (talk) 20:13, 15 December 2010 (UTC)[reply]

Suggested Merge[edit]

Year 10,000 problem → Time formatting and storage bugs

Rationale: Year 2042 problem, Year 32,768 problem, Year 65,536 problem, Year 292,277,026,596 problem and Year 170,141,183,460,469,231,731,687,303,715,884,105,727 problem already redirect to Time formatting and storage bugs, many because of prior merges. (Year 2000 problem and Year 2038 problem have separate articles because there is a lot to cover on those topics). Better to have one comprehensive and well-written article covering all these "XXXX problem" topics except those few that are too large to include. --Guy Macon (talk) 15:36, 9 December 2012 (UTC)[reply]

Survey[edit]

Add *Support or *Oppose followed by an optional one-sentence explanation, then sign your opinion with ~~~~

(Do not reply to comments here -- do that in the section below.)

Even though it is improbable, WP:REDIRECTSARECHEAP so it should not be deleted. What would the correct one be? —EncMstr (talk) 21:18, 26 December 2012 (UTC)[reply]
Well, Year 10,783,118,943,836,478,994,022,445,751,223 problem would be approximately a direct replacement, but it's hard to say that's a real date - even ignoring the fact that the Earth will have been destroyed by the end-of-life antics of the Sun long before then, the accumulated leap seconds and changes in orbits will likely add trillions of years worth of error to that number. The number above is correct assuming an unaltered Gregorian calendar following the usual 4/100/400 rules. But what then, about redirects for Year 584,554,051,223 problem, Year 5,391,559,471,918,239,497,011,222,876,596 problem, and whatever year would be implied by the signed version of the miscalculated Year 170,141,183,460,469,231,731,687,303,715,884,105,727 problem? Rwessel (talk) 21:59, 26 December 2012 (UTC)[reply]

Discussion[edit]

Add any additional comments / arguments here. According to the ISO-Standard, a thousands separator is a fixed space. (Dots and commas are - depending on language - used as decimal signs) — Preceding unsigned comment added by 213.64.113.107 (talk) 19:24, 11 August 2020 (UTC)[reply]

Off topic

We could solve this issue for the much more long-term by simply using a calendar based on the orbital period of say, Neptune or Uranus instead of Earth.

Or better yet, do away with dates altogether- as we are certainly far too focused on the "when's" and the "where's"- rather than the more important "Who's", "How's", "What's", and "WHY's".

Regardless of the number of digits used for counting years- clearly "2014" is an arbitrary value anyways- as it neither represents the verified and verifiable 'beginning' of anything, NOR is there anyone alive today (at least as far as I know) who can provide a first hand account about whether "2014" is actually even "2014", and not "2024", "1994", or "1769"...

In fact, since counting years is essentially counting the number of revolutions the Earth has made about it's star (the sun), we should in fact be counting years in some multiple of 2::pi:: radians, or more precisely whatever the general form for the circumference of an elipse is (2::pi:: being the special form for the case of a circle).

~~ — Preceding unsigned comment added by LarchOye (talk • contribs) 15:11, 8 March 2014 (UTC)[reply]

Article talk pages are for discussing improvements to their respective articles, not for general discussion of the topic. - SummerPhD (talk) 18:43, 8 March 2014 (UTC)[reply]

Year 10000 (9999), 20000 and 24613 problem[edit]

I have seen a video about Windows 10 using years 9999, 10000, 20000 and 24613. In the year 9999 was functional enough, and no year was added to 9999/10000. When the year was set to 20000, Windows set it to 20001 after reboot, and after sometime in 24613, all current Windows 10 computers simply not boot. This looks like a worse solution than in ≤7 where overflows were handled using keeping only the last 4 digits and throwing an error if year <1601. (But planned obsolescence is >2 times slower). This video demonstrates these. This can't be by overflow of the FILETIME, else Windows had the overflow 6215 years later.) Alfa-ketosav (talk) 14:12, 22 April 2019 (UTC)[reply]

Edit: Year ≤9999 problem is that the calendar doesn't work as intended. (By Alfa-ketosav (talk) 10:27, 28 December 2019 (UTC))[reply]

Edit 2: FILETIME overflows in the year 30828. (By Alfa-ketosav (talk) 09:38, 11 January 2020 (UTC))[reply]

Retrieved from "https://en.wikipedia.org/w/index.php?title=Talk:Year_10,000_problem&oldid=1063340690"