Jump to content

Talk:Year 2000 problem/Archive 2

Page contents not supported in other languages.
From Wikipedia, the free encyclopedia
Archive 1Archive 2Archive 3

worlds biggest scam?

shouldn't this be categorized as the worlds biggest money making scheme? many urban legends, and nothing actually happened besides some website displaying a wrong clock. Markthemac 02:06, 14 September 2007 (UTC)

I worked on the US government Y2K Information Center, where we had awareness of remediation efforts, as well as actual problems. As I remember, two critical systems did have malfunctions, one in a nuclear power reactor and one in an intelligence satellite system, both recoverable.
At the same time, we were aware of a great number of systems that would have malfunctioned had they not had their code updated. My impression was that the remediation effort was worth it, and prevented a fair number of things ranging from annoyances to catastrophes. For you to say it was a scam because things did not happen, are you prepared to demonstrate that nothing would have happened had code not Y2K-ready been left in place? Howard C. Berkowitz 02:35, 14 September 2007 (UTC)
No, that title belongs to Global Warming which does not have a continent end date like Y2K. 219.89.230.230 (talk) 03:54, 13 December 2007 (UTC)
It was most certainly a scam. It was an overblown fear that allowed for countless hours of useless consultancy time to be foisted off on businesses. And it also allowed more than a few corporate-ladder-climbers to make it appear that they actually contributed something. But...that's just my two cents. Personally, I am starting a new business...."Y10K Remediation Services". You think Y2K was bad? Just wait till 9999 when that fifth significant digit appears in the year-field. Anyone ready to sign a contract with me? —Preceding unsigned comment added by 208.67.104.4 (talk) 16:32, 15 April 2008 (UTC)
Speaking from first-hand experience, I can assure you it was not a scam. We tested our legacy financial services applications in 1997 by rolling the system date forward to various future dates and testing the applications. They simply didn't work correctly - even functions that we didn't think were date-dependent failed. Sometimes we had an outright crash, sometimes an error would be obvious from the data presented on screen, other times all appeared to be OK until we took a close look at the database and discovered errors. Nobody made any money out of the 18 months elapsed (10 man years) we spent modifying and testing the applications so they'd continue to function. On the contrary, the company had to spend a huge sum of money just to keep things as they stood. There were no money-grubbing consultants involved - just the staff who knew the systems and knew what needed to be done to fix them. And on a personal note, this was the most boring spell of my career as a software developer. No amount of money could have compensated for the sheer tedium of going back to COBOL and fixing thousands of date fields. Mr Barndoor (talk) 12:55, 17 April 2008 (UTC)
It was certainly not a complete fabrication, although it may well have been exagerrated to some extent, but it's often easy to be wise after the event. I did some work myself on Year 2000 problems on a medical informatics program. Maybe some money was misspent, but I query 2 of the arguments here. Firstly, while I recognise that in some countries the govt. did not do much to publicise the problem, all competent computer professionals would still have been aware of it in the late 1990s and taken appropriate action. Also, some small computer systems used by schools, small businesses etc. may not have had any problems, or just minor glitches which they could work their way around, but this would not have applied to larger or more sophisticated systems. PatGallacher (talk) 13:16, 8 October 2008 (UTC)
At work and at home I set date and time to 12-31-99 23:56 and ran the usual programs I used normally to see what would happen as year rolled over from 99 to 00. The big problem I had was that the old version Buerg's LIST program showed the first digit of the year as ":" the ASCII character after "9" in the ASCII code scheme. Our composition/photographic department used IBM PCs DOS and Windows, Apple Macs, Unix workstations, PC controllers embedded in platemakers and cameras etc., and luckily Y2K was anticlimatic. I recall patching a program to sort dated items to treat dates 00-69 prefixed with "20" and dates 70-99 prefixed with "19" but we had no systems failures or work stoppages as a result of the 99 to 00 roll-over. But quite frankly boys and girls there was no way of being sure until it was tested. It may have been a lot to do over nothing much, but it is not accurate to call it a scam because it was impossible to be sure about all program code that checked dates especially if embedded in proprietary systems where the source code was unavailable. Naaman Brown (talk) 17:23, 7 August 2009 (UTC)
Hardly a scam; While all of my code was Y2k safe since the early 90's, a lot of other software wasn't. Best case, the program crashed with no permanent damage. Worst case, a database file got corrupt, which then spat back invalid values when queried that caused much monetary pain for the effected company later on. Y2k was a problem, but most critical software was updated in time to avoid major catastrophe. Still cost a lot of companies a lot of money to resolve, however. --Gamerk2 (talk) 16:27, 2 March 2010 (UTC)
Calling the Y2K problem a scam in hindsight because you didn't see anything go wrong on 1/1/2000 is like telling someone who's just had successful triple-bypass surgery, "Hey, you look like you're doing fine—I guess you didn't need that heart surgery after all!" Nothing happened precisely because so many people worked so hard to ensure it. Gribbles (talk) 16:12, 27 August 2010 (UTC)

Just noticed the entire PSN network for playstation went down due to the 2010 date error. Thats an entire computer network, and a major player in an entire industry going down due to one date error. I think that alone proves the damage that Y2k could have [and its decendents may well still] cause if left unchecked. --Gamerk2 (talk) 16:30, 2 March 2010 (UTC)

Is this story about PSN (whatever that is?) true?
If true, just goes to show date math is difficult. The reason I went into year 2000 work in 1994 was due to my first professional programming assignment in 1971. It was some sort of insurance policy renewal work with date math all over the place. I remember thinking... "I'm 22 years old & know virtually nothing. Date math is VERY complex when combined with contract expirations & legal obligations. The chances of my learning to do such complex logic correctly was very close to zero." DEddy (talk) 17:05, 2 March 2010 (UTC)

What can not be understated is that ONLY implementations of date that used two digits were affected. Even though a printout of a date may print incorrectly due to a 2 digit display, the internal data representation may still be correct, provided the internal data itself was not a shortened two-digit year value.

Databases are a prime example: Most have a dedicated Date/Time field which stores a 4 digit year value. You can edit the output to only two digits, but the data itself is manipulated as a 4-digit value. This is perfectly Y2k safe. If, however, you were to store the year as a 2-digit Integer value (EG: 98, 99, then 99 + 1 = 100), then you could run into potential Y2K problems (which can vary, depending on the maximum size integer the database field can support; if the field can accept a 3-digit value, you get 100 representing 2000, meaning the result is a date off by 100 years. And if the field can only accept 2-digits, you get an overflow error instead).

Im oversimplifing a bit, but the point is, just because the data is incorrect doesn't mean catestrophic system shutdown will occur. 99% of the fixes I did for Y2K were Display Problems and "We assumed a 19xx year" problems, both which are easy to fix. It still cost a lot of time and money to fix, however. The 2038 problem is a far larger long-term problem, as its caused by a fundamental OS limitation, and not incorrect coding/data storage. --Gamerk2 (talk) 17:03, 12 March 2010 (UTC)

2k10 hex thing needs more explanation pls

could someone please explain in more details how systems would treat a decimal as a hex value without the creators being aware of that? --TiagoTiago (talk) 17:30, 6 January 2010 (UTC)

How could it happen? Or how could they not be aware? It could happen if the coders insisted on using two character years and compensated by changing the year to hex (base 16, 00 thru FF) but other systems not supporting this shift so they still use decimal numbers. It coud be overlooked because the writers are no longer employed with the company, have died, were only brought in to fix the problem quickly, several reasons. Padillah (talk) 20:35, 6 January 2010 (UTC)
The current explanation is horrible. The actual problem is probably that people were treating Binary-coded decimal (BCD) as binary. Since SMSes encode the date in BCD, that was almost certainly the problem with the mobile phones. 0x10 is 10 in BCD, but 16 in binary. Thue | talk 17:35, 7 January 2010 (UTC)
Less likely: Some cases could also be the "windowing" hack described in this Y2K, where the fix "windows" 10 to 1910. But this is pure speculation. Thue | talk 17:38, 7 January 2010 (UTC)

I added some explanation based on (1) [1] (2) Technical reasoning (3) A survey of the already linked articles about problems. I am pretty sure it is correct, but I don't have a real reference for it, so right now it rightly has a {cn} tag on it. But I though that was better than no explanation at all, or the previous unreferenced vague hints at an explanation. Thue | talk 16:57, 8 January 2010 (UTC)

Year 1900 Problem anecdote

From 1955 to 1958 I worked in the Hollerith dept of Kodak in the UK, in north Harrow, Greater London. Of the maybe 6000 people who worked in the Harrow factory, very few seem to have been born before 1900 - so few that the systems didn't provide for this. Very occasionally (memory says a very few times in a monthly or quarterly "run"), one of the machines, a 542 electronic multiplier, would come to a stop. Invariably it was due to someone born before 1900. With space at a high premium in 80-column punched cards, only two columns were allocated to year of birth. (if this story belongs in the Year 1900 Problem talk page, I apologise: I don't know how to start a Talk page there.) Forton (talk) 03:53, 26 January 2010 (UTC)

PS3 reference in Year 2010 section

The Year 2010 problem refers to the bug when the year changes from 2009 to 2010. The PS3 problem in March 2010 is a leap year problem - the problem stemmed from the internal clock identifying erroneously that 2010 is a leap year, not from the year changing from 2009 to 2010. 222.153.247.229 (talk) 05:15, 3 March 2010 (UTC)

If memory serves... the rules for calculating a leap year are: (1) divisible by 400 IS a leap year; (2) divisible by 100 is NOT a leap year, and (3) divisible by 4 IS a leap year. 2010 does not satisfy any of those conditions, so while the symptoms are LIKE a leap year (February 29) problem, it's probably something else. Or they invented yet another really odd date calculation. DEddy (talk) 02:59, 4 March 2010 (UTC)

Information Crisis article

We seem to be having an edit war, with some editors wanting to link this article to one called "Information Crisis". The problem is that the Information Crisis article is junk, and should be deleted rather than linked to. Its only references are to works of fiction, and it says Y2K never happened - an odd thing for an article on Y2K to link to. No wonder it's an orphan article. Information Crisis fails the quality test for me. I'll revert the edit again, and I suggest that anyone who wants to link to that article justifies doing so. Mr Barndoor (talk) 15:05, 26 July 2010 (UTC)

The Information crisis article is an orphaned stub, and editors from Wikipedia:WikiProject Orphanage are attempting in good faith to resolve the orphan status by linking to it from the most relevant articles.
I agree that Information crisis is (per your edit summary) "a very poor article", but we should never delete a wikilink because a potentially highly-relevant article is, in itself, "not worth linking to". We should either remove the article, or improve it. I've gone ahead and nominated it for deletion to see what happens. --McGeddon (talk) 15:26, 26 July 2010 (UTC)
You seem to be having the edit war and this is an example of page ownership: deleting content and then saying "let's take this to the talk page". With that off my back I'll respond: it's a stub not a poor article. It should be improved. Until such time as it is deleted, it should be linked to this article since it's valid content and related to the subject. Restoring. --Walter Görlitz (talk) 19:58, 26 July 2010 (UTC)
Nonsense. Even if that article (Information crisis) were about a real encyclopedic topic, it's relevance to this article is marginal. Removing again. — Arthur Rubin (talk) 20:05, 26 July 2010 (UTC)
Please don't be obstinate. I don't think you've read the information listed there. An information crisis would have been what would have happened had I and thousands of others not worked tireless hours to prevent it. How can you say it's not relevant to this article? Also, if you don't like the information crisis article nominate it for deletion, but it should stay linked to this article as valid and relevant until it's no longer a part of Wikipedia. You have not made a single valid reason to not include it. --Walter Görlitz (talk) 21:42, 26 July 2010 (UTC)
Information crisis had already been nominated for deletion before my last removal. And there is no evidence that, even if the worst Y2K scenarios had ensued, that there would have been something resembling an information crisis. Many systems would (in that scenario) have gone out, but the Internet probably would have remained up as long as the power. That doesn't match what the article information crisis uses as a "definition". — Arthur Rubin (talk) 21:55, 26 July 2010 (UTC)
The Internet may or may not have worked, but that's not the point. This isn't about the Internet. It's about computer systems malfunctioning, not just one type. So if Y2K hadn't been fixed before the deadline systems would have malfunctioned. In some scenarios this would have meant the system would have not worked at all. In other instances, it would have meant that posting dates would have been wrong. What too many people continually miss about the Y2K problem is that it was averted through diligent effort not through lack of a problem. --Walter Görlitz (talk) 22:24, 26 July 2010 (UTC)
As you said, information wouldn't be lost in the Y2K scenarios; it just wouldn't be readily available.
As for your statement that "it was averted through diligent effort", that may be true. If so, it should be sourced and placed in this article. I believe the present article leaves it open whether there would have been a significant problem had the work not been done, with both sides have reliable sources.
Finally, the link in information crisis to this article is misleading. Even if the article is kept,, that statement should be modified. — Arthur Rubin (talk) 22:37, 26 July 2010 (UTC)
I also said, or at least should have, that there was no way of really knowing what would have happened. Information could have been lost. The fact that the Y2K problem was averted through diligent effort is cited throughout the article. How can a "see also" be misleading? --Walter Görlitz (talk) 22:45, 26 July 2010 (UTC)
In my opinion the great tragedy of Y2K efforts is that the term was hi-jacked by the end-of-the-world element. I saw Y2K as a technical & project management issue. I was dead wrong. To my utter surprise selling the end-of-the-world (EOTW) is a big business with substantial legs. A LOT of people believe in EOTW. 2000-01-01 was a convenient real deadline. The incessant drumbeat for the electricity grid collapsing didn't help. To the vast majority of people computers & systems are totally black magic... particularly senior management. And then when the world didn't collapse at midnight, a LOT of people were disappointed. This is not a contradictory statement: I absolutely know problems with 2 digit years was a real issue, and most people totally believe the whole thing was a hoax. So associating Y2K with "information crisis" strikes me as crying wolf. There are plenty of lessons we DID NOT LEARN from Y2K. DEddy (talk) 23:34, 26 July 2010 (UTC)
I have no idea what that rambling was about. The information crisis was averted. That's why the two should be linked. It has nothing to do with doomsday scenarios. The fact that you think they shouldn't be linked isn't really supported in this article. --Walter Görlitz (talk) 23:48, 26 July 2010 (UTC)
I'm sorry I couldn't make the connection... far more people believe in the EOTW than believe there was a Y2K crisis. Since the world did not collapse the majority obviously believe (then & now) all the noise about the (very real) Y2K technical challenge was a hoax. To attempt to associate an "information crisis" with a non-event does not help in arguing that Y2K (the technical challenge) was real. DEddy (talk) 00:05, 27 July 2010 (UTC)
Understand your point now, but I disagree in the argument. --Walter Görlitz (talk) 00:58, 27 July 2010 (UTC)

For the Record

The "reason" I coined Y2K was that I was lazy & tired of typing "year 2000". Y2K is a 67% savings over "year 2000".... pure & simple. Shortening terms to cryptic acronyms/abbreviations is simply a skill acquired by spending too much time at the keyboard. DEddy (talk) 23:16, 5 October 2010 (UTC)

4 digit years on forms

The point is that printing or allowing room for 4 digit years on forms has absolutely NO impact on how a computer system deals with the year. Might give humans a warm fuzzy feeling, but does nothing to how the software works.

Also... "all banks in Canada" is a rather sweeping statement. Evidence? DEddy (talk) 01:24, 8 October 2010 (UTC)

http://www.rbcroyalbank.com/standard006/index.html also http://www.cdnpay.ca/imis15/eng/FAQs/Cheque_Specifications/eng/faq/Cheque_Specifications.aspx#Date_Field "the three permissible numeric date formats is used (i.e. YYYYMMDD, MMDDYYYY or DDMMYYYY)". The reason is so that computers can easily scan the cheques and process the information without humans and their warm fuzzy interpretation of the data. This is how software in a developed country works. You should join a developed country so you can see what it's like. --Walter Görlitz (talk) 02:15, 8 October 2010 (UTC)
That's just a statement of intent for scanning check images from a single institution. Is there a Canadian law with enforcement clout that actually reaches inside the systems? Actually expanding from YY to YYYY would be a BIG deal. It's been my understanding the most popular approach to put off solving this issue was to use sliding windows. It says nothing about the systems that actually process the information getting scraped off the checks. DDA systems tend to be the oldest of the old in banks so every movement of data fields needs to be examined to ensure a YYYY to YY hasn't happened at some point. As positive as my experiences have been with Canadian banks, they're just banks. Basic rule-of-thumb for financial institutions of all strips is "Fancier the facade, the more chaotic the back office." DEddy (talk) 18:15, 8 October 2010 (UTC)
It's the only company in Canada that clears cheques. If the banks don't work with this company they can't issue cheques in Canada. They can't get money from other financial institutions if they receive cheques from them. The link at the Royal Bank, a consumer bank, alludes to this. There are no Canadian laws of which I'm aware. --Walter Görlitz (talk) 13:49, 8 October 2010 (UTC)
Please explain how putting a 4 digit year on a printed form is going to impact software applications?
An international banking application used by a Canadian bank certainly used 2 digit years as of 1994. Since I wrote the check output (banker's acceptances) I 100% know it would have printed 1900... unless someone went in & changed the code I wrote. Since 11% of the fields in the system were actually dates the chance of changing from YY to YYYY are pretty slim... that would have been a major, major effort... for a single system. DEddy (talk) 18:24, 8 October 2010 (UTC)
It's not up to me to explain but to simply give a WP:V source, and you have two. 1994 is not 2001, when I got my first four-digit year cheques from my bank in anticipation of the new requirements where were to be in place in 2005. --Walter Görlitz (talk) 18:37, 8 October 2010 (UTC)
I'm still at a loss here... what do specifications to print 4 digit years on paper checks/cheques have to do with the operational software systems behind the scenes? Are you arguing that publishing such EXTERNAL specifications (it's certainly a good step... but only a beginning... I would certainly be happy to argue the additional formats of MMDDYYYY & DDMMYYYY should NOT be permitted... they're too ambiguous) impact the software that processes the information coming off the checks/cheques? DEddy (talk) 19:34, 8 October 2010 (UTC)
I'm so sorry for your loss. All I know is that when they were introduced the wording used was in effect to avoid another Y2K situation. --Walter Görlitz (talk) 19:56, 8 October 2010 (UTC)
I'm trying to make the connection between that EXTERNAL specification for printed documents and the INTERNAL workings of software applications. Can you help? Do you believe there's a direct connection between between the external & the internal? Isn't 2005 a bit late? Surely no organization—Canadian or otherwise—is going to spend effort for the 2100 project, 90 years away. Actually probably sooner if windowing was used to deal with 20000101. DEddy (talk) 20:11, 8 October 2010 (UTC)

IPv4 address exhaustion

Don't think it should be in the See also section. An editor added it, I removed it, another editor restored it. Here's the deal. IPv4 had a known limitation when it started as did omitting century (and millennium) from stored years. That's the only similarity: it was planned. The date storage issue became a crisis while IPv4 has not because of various issues. IPv6 is being rolled-out slowly and its implementation is not complete whereas there was a deadline for the storage issue. If IPv4 continues for another decade, there is likely not going to be an end to existing system functionality, whereas there were serious consequences and loss of data had the date storage issue not been addressed. Unless the proponents can offer something more substantial than lack of planning, (which was not short-sighted for either issue as Medeis stated) it should not be part of the See also section. --Walter Görlitz (talk) 19:19, 24 January 2011 (UTC)

See also sections deal precisely with topics of a similar nature of possible interest to readers. This is an issue of format limitations that deal with computing. This link may interest some readers and does absolutely no harm. μηδείς (talk) 19:23, 24 January 2011 (UTC)
So I should add every possible date format, computer operating system, storage device and format, databases, national date formats, computer languages, development, and anything that might interest? That's not what it says at WP:ALSO. Unless you can come up with a better explanation, I will be either forced to remove this nonsense or discuss it with the relevant groups to gain consensus.
The fact that it's not sufficiently similar is reason enough to exclude it. IPV4 is not a format limitation, it was a simplicity issue, as was demonstrated in my first paragraph. I notice that there's no link back from that article to this one so another group agrees that they're nor similar. --Walter Görlitz (talk) 20:22, 24 January 2011 (UTC)
The issue is this link in this article, not every possibly imagined link in every article to which you personally think you might object. I do not edit IPV4 so I am not about to go there as if I am a stalker. I am not so emotionally invested in this. Consider the simple fact that the IPV4 situation is a formatting issue affecting computing which, especially given its current newsworthiness, is of possible interest to readers of this article. You obviously have a strong personal POV, but no one has claimed that the issues are identical in all aspects, only that the two phenomena fit under the same broad category of computer formatting issues with broad impact. The presence of the link in no way overburdens the article or harms readers but the absence of the link absolutely ensures that readers of this article unfamiliar with the issue will remain ignorant.μηδείς (talk) 21:29, 24 January 2011 (UTC)

A few of the 247,000 google hits mentioning Y2K and IPv4 in the same breath:

RE: IPv4 to IPv6 transition Oct 4, 2007 ... The Y2K issue was almost certainly overblown, but it is important to understand the reasons as they do not apply in the IPv4 case. ... www.ietf.org/mail-archive/web/ietf/current/msg48336.html - Cached App Performance View: IPV4 to IPV6 Migration, the 'Real' Y2K ... May 25, 2010 ... Failure to migrate to IPV6 will create performance 'speed bumps' www.networkworld.com/.../ipv4-ipv6-migration-‘real’-y2k-problem - Cached IPv6 vs. Y2K and GOSIP Dec 17, 2007 ... I don't see any kind of Y2K-like panic among federal CIOs ... www.networkworld.com/.../121707-how-the-feds-are-dropping-the-ball-side -2.html - Cached - Similar Show more results from networkworld.com IPv4 To Become The Next Y2K? « IT Professionals IPv4 To Become The Next Y2K? « Previous Next ». by Matt Hartley on 07/22/2010 3 Responses (Thoughts?) There should be an image here! ... www.lockergnome.com/it/2010/07/22/ipv4-to-becoming-the-next-y2k/ The Next Y2K Project: The End of IPv4 | CRM Help Desk Software.com Nov 9, 2010 ... Remember Analog TV Transmission? A thing of the past? I grew up with an analog B&W television. Rabbit ears and all. Hey, it worked. crmhelpdesksoftware.com/the-next-y2k-project-the-end-of-ipv4/ - Cached IPV4 switch over to IPV6 is this the next y2k? 2 posts - 2 authors - Last post: Aug 5, 2010 I heard this on the radio this evening on the way home. They were saying that the change over which is supposed to happen in the next few ... www.survivalandpreparednessforum.com/showthread.php?...IPV4...y2k - Cached Security World: IPV4 to IPV6 migration: the 'real' Y2K problem Many believe that warnings about the perils of running out of IPV4 addresses can safely be ignored -- that like the Y2K machinations of the last century, ... security-world.blogspot.com/.../ipv4-to-ipv6-migration-real-y2k-problem. html - Cached Lexi Net » IPv6: It's Y2K Again While the potential problems associated with IPv4 runout are not nearly as difficult as Y2K, and they will not happen all at once, they are, nevertheless, ... www.lexi.net/blog/archives/63 - Cached Will the switch between IPV4 to IPV6 be the next Y2K ... Nov 8, 2010 ... As the transition from IPV4 to IPV6 begins to occur, people need to understand what it is and that it will effect them physically since a ... michaelbastos.posterous.com/will-the-switch-between-ipv4-to-ipv6-be-the-n - Cached

I am inclined to think that Y2K and IPv4 suffer from a similar problem. Namely, running out of space in the allocated field size to store the required information. IPV4 needs (at least) one more bit, but we have none available. Y2K needed another digit (or two) but we had no space to put them. Looks kind of similar to me. HumphreyW (talk) 21:35, 24 January 2011 (UTC)
Not a similar problem. Let me state this again. The date issue was a storage issue. Programmers wanted to save storage space in a database. IPV4 was done not to save space in a storage facility, but because it was more than adequate at the time.
As for google hits, how many billion hits don't mention them in the same article? Since you're not willing to stir-up a hornet's nest, I will. --Walter Görlitz (talk) 22:32, 24 January 2011 (UTC)
At first, I thought the address exhaustion link was inappropriate. But, after hours of reflection, it now strikes me as an excellent contrast to what is essentially the same problem: The implementers of each (two digit years and 32-bit node addresses—and, for that matter 16-bit CPU address buses (64 K of memory is enough for anyone), and international hub airports with too few gates—chose to solve a problem based on the economics of the time, knowing full well that their solution would affect the future with a much bigger and possibly more expensive problem. However, given the uncertainty of the future and the certainty of the present, one has to engineer a solution which appropriately weights each. Two digit years had a specific, well-known deadline. But some new code was written as late as 1998 (where I worked) that failed to avoid problems on 2000-01-01—I don't understand the engineer's thinking, but I suspect apathy, belief in magic (that some global solution would fix it automatically), going along with the past, not believing the code would still be in use, or a cognitive disconnect between the implementer's actions and how that affects the client.
The comparison is less striking for knowing in advance when the problem would occur. For IP addresses, resourceful solutions have delayed exhaustion several times, as well as simple changes in perception—for example, each node inside a university does not need its own world-visible IP address as was imagined at inception. —EncMstr (talk) 22:50, 24 January 2011 (UTC)
I only inserted a link to the IPv4 exhaustion because I felt it was similar to the Y2K problem in the way that both are technology-related problems that are/were forecast to create problems when a certain date arrived. Since IPv4 was in the news lately, I thought of this article and decided to add a see also link, but did not anticipate the multi-editor argument that ensued. If editors should decide that the link is too off-topic, then I don't mind not having it in the see also section. ~AH1(TCU) 22:55, 24 January 2011 (UTC)
I am of the opinion that the link does not belong. A fundamental difference between the two problems is that when programmers chose to store the year as two digits, they truncated an existing value, with the implication that the value would be expanded out to the correct value when it was read from storage. With IPv4, there were no existing values or count of computers to truncate - the size of the address was a decision based on expected requirements, not the number of computers in the world at the time. (IPv4 is more like a "see also" to the 640 kB barrier.) IPv4 would have been a "see also" if its creators had (for example) devised a scheme whereby the stored 4-byte IP address was unique within each country only, but they didn't allocate another byte to specify the country, because "we all know what country the computer is in". A closer analogy would be Local conventions for writing telephone numbers, whereby "Writing a telephone number ... may lead to incorrect dialing when area codes are omitted for local calls." The country and/or area codes are analogous to the century - not stored/written, but implied. It works fine if you're in the same country/area [century] but fails if you're not. It appears (WP:OR) quite common for USA publications to list a telephone number with an area code but no country code - even when the publication will appear in a different country. Mitch Ames (talk) 05:14, 26 January 2011 (UTC)
Does every "see also" link have to be exactly the same thing as the subject of the article? Readers can be informed about a similar problem (i.e. IPv4) without having to expect the problem to be precisely the same thing. It doesn't matter if technically the historical reasons for IPv4 and Y2K are not the same, there is still a link between the two things, even if not a direct link. I don't see the link as harming the article in any way. It can be helpful to some readers, so I can't see why there is so much resistance to having it there. HumphreyW (talk) 05:43, 26 January 2011 (UTC)
Certainly. I'll get around to adding the article on the Gregorian calendar shortly, specifically referencing the problems encountered in its adoption since it has to do with dates. And after that, perhaps a link to databases and data storage, since that's what's at the heart of this problem. An appropriate see also to every operating system that had to be patched at the time will be added shortly after that, and a link to Microsoft Excel since they'll be experiencing a crisis in 2038. Anything I'm missing? --Walter Görlitz (talk) 05:52, 26 January 2011 (UTC)
In short, the editors of IPv4 address exhaustion don't seem to mind to have this article linked in that article's see also section so I have once again made a mountain out of a molehill. No need to continue to defend the addition. I acquiesce to consensus. --Walter Görlitz (talk) 05:54, 26 January 2011 (UTC)

(After Edit conflict) I am one of those programmers from the 1970s who "caused" the Y2K problem. (Well, I don't think any of my programs from those days actually lasted until 2000, but I did store the year as two characters hundreds of times, maybe thousands.) I'm happy for there to be a See also to IPV4. It's another problem related to shortness of a resource that only exists in electronic form. Certainly not a related problem, but hey, times have changed. HiLo48 (talk) 06:00, 26 January 2011 (UTC)

I continue to think that the link does not belong, but I'll accept any other consensus and not change the article either way. However, I think that if the link does stay, we should "... should provide a brief annotation ..." as per WP:SEEALSO, because - in my opinion - the "... link's relevance is not immediately apparent". Mitch Ames (talk) 07:54, 26 January 2011 (UTC)

Does anyone else have an opinion on whether we should provide a brief annotation to the "See also" entry because the link's relevance is not immediately apparent? Could any of the editors who think that the link is appropriate write such a brief annotation? Or are those editors also asserting that the relevance is immediately apparent? Mitch Ames (talk) 02:48, 4 February 2011 (UTC)
Address exhaustion is plain English in my book, but feel free.μηδείς (talk) 02:52, 4 February 2011 (UTC)
I took a whack. Please improve if you can. —EncMstr (talk) 05:43, 4 February 2011 (UTC)

Date bugs similar (or not) to Y2K

I deleted and Medeis restored several "problems" that I claim are not "similar to Y2K". In answer to Medeis' question "how not similar?":

The Y2K problem is caused by a design limitation. Correctly written code would originally always turn a year stored as xx into 19xx or possibly 1900+xx (eg xx=16 becomes 2016). Later code might assume that if xx>70 (for example) treat as 19xx, else treat as 20xx. In any case there is a well known design limitation, a clear rule, and the programmer follows it. Ie in general, the Y2K problem is not caused by programmer making a mistake in the code and failing to code to the specification. Even with perfect programmers who never made a mistake, a problem would occur (given the storage of a year as two digits).

However the other problems are caused by poor programming, or poor understanding of the rules - they are not limitations of the way the data is stored. A good programmer, knowing the rules can always get the correct output. Failure to do so is a programming error, not a fundamental design limitations. At worst (eg with the year 2010 problem) the failure might be caused by poor specification (failure to define whether a number is stored as BCD), but that is quite distinctly different from the Y2K bug that is caused by a design with a known limitation.

Thus I still assert that "leap year", "year 2010" and "confusion between day and year" are bugs due to bad programming or poor specification - which is not "similar" to the problem caused by inadequate space to store the year, and thus they should be removed from the article. Mitch Ames (talk) 12:17, 16 February 2011 (UTC)

They are from limitations of the way the data was stored. When every byte was worth more than your daily salary, you learned to cut corners. --Walter Görlitz (talk) 14:57, 16 February 2011 (UTC)
Year 2010 problem - BCD and hexadecimal encoding (eg 0x10 vs 0x0A) use the same amount of space. The error in interpretation of the value has nothing do do with reducing data storage requirements.
Leap years - quoting from the article:

Some programs ... relied on the oversimplified rule that a year divisible by four is a leap year. ... Other programs contained incorrect leap year logic, assuming for instance that no year divisible by 100 could be a leap year.

Nothing there about the year being stored in two digits - only erroneous implementation of the algorithm or incorrect logic. Again, nothing to do with reducing data storage requirements, ie not similar to Y2K. Mitch Ames (talk) 12:09, 17 February 2011 (UTC)

The real reason why Y2K was a problem

Obviously the people writing comments in this Discussion have NFI about the problem. Back in 1990, a new disc drive of 1.2G capacity was the size of a 'chest of draws'. It had eight discs, four read/write arms and probably costed more than a family car; at the time. Cost of storage was the issue, so only the two digit year was used. Imagine, for example, the social outcome if all interest was calculated using a two-digit number. 12/99 minus 01/00 equals 98 years and 1 month. Assuming $10 per month, the interest payable/received would be $11,880. Now multiply that by the average mortgage! Think about it. Molbrum (talk) 15:52, 13 July 2011 (UTC)

Software Bug?

How was Y2K a bug? Using 2 vs 4 digit years was a conscious design decision. Keypunching was expensive, cards were limited to 80 characters, storage was expensive & limited, processing was slow. At the time 2 digits was a reasonable decision. Unreasonable was allowing 2 digits to stay in use for decades. Judging a 1940s/1950s/1960s/1970s decision through the lens of 1990s technical capabilities is not legitimate. That management should have known better & spent the money to convert from 2 to 4 digits at leisure in the 1980s... that's a separate issue. DEddy (talk) 14:22, 12 February 2012 (UTC)

Good point. However, this wasn't a perspective issue. Many conscious design decisions end up being bugs despite the idea that a the difference between a bug and a feature is one that is documented. The term was just used to describe it but it wasn't technically a bug. --Walter Görlitz (talk) 21:20, 12 February 2012 (UTC)

Readability

This sentence: "There were plenty of other Y2K problems, and that none of the glitches caused major incidents is seen by some, such as the Director of the UN-backed International Y2K Co-operation Centre and the head of the UK's Taskforce 2000, as vindication of the Y2K preparation." is written in kind of a ridiculous way. Can we find some way to rewrite it that would increase its readability? --192.91.171.36 (talk) 21:48, 22 February 2012 (UTC)

Mass Panic

I have to admit, I was only 7 when this happened, so I don't REALLY remember, but wasn't there some sort of comically exaggerated mass panic, specifically in the United States? I seem to remember stories about people rushing to grocery stores and buying massive amounts of frozen foods. Isn't this something that should be talked about more in the article? — Preceding unsigned comment added by Rockslideproductions (talk • contribs) 06:33, 2 February 2012 (UTC)

If you can find some sources, feel free to discuss it. There wasn't mass panic though. There were isolated incidences of people hoarding food, fuel or money but it wasn't widespread. --Walter Görlitz (talk) 15:19, 2 February 2012 (UTC)
I remember the panic among some. I remember people asking each other "do you believe in y2k?". I remember Australia's new years celebration being shown on American t.v. and people being relieved their country didn't explode. The fear mongering accusations are referenced but there's no mention of the actual fear that it did create among some (all though I admit many people laughed at them) I feel the panic is understated in the article. I came to read about it for nostalgia sake and I'm very surprised the panic isn't directly written about, but only referenced through peoples criticism of the seriousness of the situation. — Preceding unsigned comment added by 174.253.151.226 (talk) 14:35, 29 February 2012 (UTC)
If you know of a reliable source with a published account of panic and fear, please add it to the article. —EncMstr (talk) 16:41, 29 February 2012 (UTC)

Citation Error

Citation # 43 is logically self-crippling. An article about how something helped on 9/11/2001 CANNOT have been published in 2000. 98.210.102.208 (talk) 09:08, 28 February 2012 (UTC)

Now fixed. HumphreyW (talk) 09:21, 28 February 2012 (UTC)

Recent edits.

Gorlitz, based on this confusing edit summary could you please explain more clearly what your rationale is? I am finding it hard to follow your arguments based on one-line edit summaries.

I'm quite willing to listen to reason, but I don't see any yet. What are you saying is not supported? If you agree that my own rationale was valid, then why did you revert - again? Chaheel Riens (talk) 22:09, 29 June 2012 (UTC)

You're changing 154 to 158. Source clearly indicates "The health service is facing big compensation claims after admitting yesterday that failure to spot a millennium bug computer error led to incorrect Down's syndrome test results being sent to 154 pregnant women." So why do you keep changing the referenced material to 158? I'm assuming that you're assuming that 154 + 4 = 158, but that's not stated in the reference. Rather those four who had Downs Syndrome children were likely in the 154 (150 + 4). Also, if you are going to do 154 + 4, you should also lump in the "two terminations". Also, the loss of life is an important separate point to make. --Walter Görlitz (talk) 22:20, 29 June 2012 (UTC)
Right, that makes a lot more sense. I've re-read the source, and agree with your intepretation. You know, that would have been much easier if you'd stated that in the first place rther than the confusing and contradictory edit summaries you used instead.
Two final points though - I don't know why you feel it necessary to stress "the loss of life is an important separate point to make", seeing as I left in that comment in and made no changes there. Also, I left a note on your talk page as quite the opposite to your edit summary, I expected that a prolific editor such as you will most likely have hundreds if not thousand(s) of pages in your watchlist and a relatively small edit to a talk page could well be missed - especially if it took a while for you to log back in and the page may have been updated by another editor in the meantime. Chaheel Riens (talk) 06:39, 1 July 2012 (UTC)

Citation?

Isn't the quote in the body of the RadioWorks clip? What more is needed to be be a "citation?" DEddy (talk) 01:51, 21 July 2012 (UTC)

Bulgaria

Not only is the recently deleted material verifiable (Iliana V. Kohler, Jordan Kaltchev, Mariana Dimova, "Integrated Information System for Demographic Statistics 'ESGRAON-TDS' in Bulgaria" Demographic Research, VOLUME 6 - ARTICLE 12, PAGES 325 - 354[2]), the section can be expanded with the following information from the IAEA report The impact of the year 2000 issue on electricity grid performance and nuclear power plant operation in Bulgaria, the Russian Federation and Slovakia [3]

BULGARIA Bulgaria set up a special council of experts for the power sector and initiated actions to respond to the Y2K problem in accordance with the President of the Committee of Energy’s Order Number 317/01.09.98. Actions required by this order include an inventory of the information and management systems of all elements. As of December 7, 1998 seventy-two of these organizations (from a total of 74 companies and 30 branches) have completed estimates of the problems and funds required. The considerations involved in planning and implementing activities for coping with the Y2K problem included examination of internal and external interfaces, clarification of supplier related issues, preparing scenarios for critical systems, and for new orders requiring supplier warrantees related to Y2K compliance. The systems analysis task performed included: (1) identification of critical time periods; (2) analyses of software upgrades to be made based on by software suppliers information; (3) fixing probable disturbance sources in systems software; (4) preparation of needed corrections; (5) evaluation of test configurations to simulate possible operational schemes; (6) implementation and testing of necessary modifications; (7) system upgrades with Y2K compatible versions; (8) fixing necessary hardware upgrades using new versions. The control systems within the power plants are also being evaluated. In the Bulgarian power system there are 2820 MW of thermal and 1590 MW of hydroelectric generation capacity with 14 thermal and 26 hydroelectric units that can be involved in direct load frequency control from national dispatching center. The units control systems had different suppliers: ABB, Siemens, Toshiba and control system produced in Bulgaria — MICROSYST. The new SCADA/EMS (supervisory control and data acquisition) system at the Bulgarian national control center are scheduled to be in regular operation by April 1999. The hardware, the UNIX 4.0 D operating system, and the application software are Y2K ready. Telecom equipment (type Telegyr 065, 709, 709s, 803, 809) installed in power plants, substations and control centers is Y2K ready. The systems at the regional dispatching centers and at control center of the city of Sofia, a distribution control center, are also being upgraded. Y2K is also a reason for the hardware upgrades. These upgrades will be completed by September 1999. 4 Following preliminary analyses, Y2K simulation tests were conducted. These tests of the Bulgarian power system were completed on 8 October 1998. All systems operated normally except for problems with archive searches for the time period 1999 and 2000. Additional activities are planned. Action is in progress on telecommunications. The general conclusion is that the problem is under control. Testing showed no problem with automatic generator control or real time power application programs. Work to evaluate interfaces with neighbors systems, telecommunications, etc. is reasonably established and is in progress. The conclusion, presented by Bulgaria, based on these tests, was that performing such tests of systems and documenting these tests may prove useful exercise for everybody in the region. The procedure used by Bulgaria of analyzing the situation (initial assessment), contacting suppliers (vendor evaluation), and proceeding on this basis provides a few simple initial steps. Power plants, regional control centers, and then national centers should be checked. An assessment could then be made of these systems. Then, after completion of the preliminary steps, Y2K simulation tests could be done by changing dates. — Preceding unsigned comment added by Medeis (talk • contribs) 21:58:10, 15 January 2011 (UTC)

An article about a precise problem should use precise language

I am not wrong about this. "Even" means "divisible by 2". "Evenly even" means "twice divisible by 2". "Evenly divisible" is therefore ambiguous because it can refer to the sense of having no remainder or the sense of being able to do it twice. For this reason, the term has rightly been dropped from mathematical usage as explained in Parity (mathematics). I am not the only one who has found the term ambiguous either [4]. The word "divisible" contains all the information that would be required in that sentence and none of the confusion. Connor Behan (talk) 05:42, 17 June 2012 (UTC)

Is 3 "divisible" by 2? Of course it is!
How do you feel about exactly divisible? —EncMstr (talk) 06:11, 17 June 2012 (UTC)
"evenly divisible" is common English phrase meaning leaving no remainder after division. I seriously doubt anyone has read that incorrectly (except perhaps for Connor Behan). HumphreyW (talk) 08:58, 17 June 2012 (UTC)
HumphreyW has the correct understanding. Connor Behan does not. Even does not mean divisible by two, but we're not talking about even and odd numbers but rather numbers that are "evenly divisible". --Walter Görlitz (talk) 15:53, 17 June 2012 (UTC)
I am not talking about even and odd numbers either. I am using them to illustrate the fact that "evenly" is an ambiguous adverb. Yes, "evenly divisible" is a common English LAYMAN phrase and I would like this article to be held to a higher standard. Only people in pure mathematics are likely to read it incorrectly but that is not the point. An article about dinosaurs could say "brontosaurus" or it could say "apatosaurus". Everyone would know what you mean either way, but one is correct and one is not. I have changed the word to "exactly divisible" if using the accepted term "divisible" is too scary for you. Connor Behan (talk) 19:38, 17 June 2012 (UTC)
Not being wrong is not the standard for inclusion in a wikipedia article. As for "Evenly even" means "twice divisible by 2", it still requires a footnote from a reliable source since the WP:RS standard is "requires inline citations for any material challenged or likely to be challenged" ( Martin | talk • contribs 17:47, 19 September 2012 (UTC))
9 is evenly divisible by 3. Does this need to be said? (Or just "divisible".) Now I am slightly spooked about editing this article if there is a question about even or odd or divisibility. ( Martin | talk • contribs 17:51, 19 September 2012 (UTC))

The reference to Parity (mathematics) is a little misleading. That page states (without giving a source) that the phrase "evenly divisible" is old-fashioned, but means the same as "divisible". It does not support the interpretation "twice divisible by 2", and does not give such a reason for the phrase being dropped. Outside formal mathematical writing, the phrase "evenly divisible" is still commonly used (see its wiktionary entry, or just type the phrase into a search engine and see how many hits you get), and I see nothing wrong with using it on this page. Jowa fan (talk) 05:11, 18 June 2012 (UTC)

Nice to hear a mathematician's opinion on this. Yeah I guess the parity article doesn't suffice by itself. It was more of a "fallback argument": 1. "Divisible" and "evenly divisible" mean the same thing to most people so who cares? 2. If that doesn't work for you, consider parity (mathematics) informing us that the latter term is non-standard. 3. If that doesn't work for you, consider the other link [5] (I am not the person on that forum) which DOES address even/odd confusion. But changing peoples' attitudes on this matter is proving to be a more daunting task than I had hoped. Therefore I will stick to more technical articles about theorems and such and hope that others follow that example. Connor Behan (talk) 06:52, 18 June 2012 (UTC)
Please stop messing around with "evenly divisible" at large number of articles until the discussion at Wikipedia talk:Manual of Style/Mathematics reaches a conclusion; I will begin a discussion there momentarily. Jc3s5h (talk) 11:16, 18 June 2012 (UTC)

Event horizon

The article has this near the start: This has caused some date-related processing to operate incorrectly for dates and times on and after 1 January 2000, and on other critical dates which were billed "event horizons". Without corrective action, long-working systems would break down when the "...97, 98, 99, 00..." ascending numbering assumption suddenly became invalid. A few problems with this formulation.

  • "time". was not involved in Y2K
  • "On and after". The bug would not manifest "on or after" January 1st. The ambiguity existed without respect to the date that the program was run, unless the test involved was against the current date. Even in that case, the test might fail on January 1st (is a date in the past), or begin to work again on January 1st (is a date in the future). The date that the comparison takes places is not relevant to the ambiguity in the data: a comparison of two dates that do not contain century information relies, by default, on the assumption that the missing century information is irrelevant - that is, that the two dates being compared are in the same century.
  • the notion of "breaking down" of the series 98 99 00 could, and should, be put more clearly.
  • this use of "event horizon", while imaginative and possibly suggestive, is hardly clear; especially for a problem that many understood clearly and precisely. The linked to wiki article "event horizon" has no information on Y2K, and the article gives no guidance on how to apply the concept.( Martin | talk • contribs 18:10, 19 September 2012 (UTC))
The wikilink does not need to have a section about Y2K, it is meant to help the reader understand that phrase more fully. Agree that time was not involved with Y2K, although it does with epoch-based computer time representation. --Walter Görlitz (talk) 18:40, 19 September 2012 (UTC)

Some such. "Some such"?

Text is
Many computer programs stored years with only two decimal digits; for example, 1980 would be stored as 80. Some such programs could not distinguish between the year 2000 and the year 1900. Other programs would try to represent the year 2000 as 19100[citation needed]. This could cause a complete failure and cause date comparisons to produce incorrect results. Some embedded systems, making use of similar date logic, were expected to fail and cause utilities and other crucial infrastructure to fail.

Let's see, how about something like:
Many programs stored years without the century, assuming that the century was 19. 1980 was stored as 80. As the 21st Century drew nearer, this assumption of 19 as the century became increasingly incorrect. Just as it is not possible to tell whether March 15 is before or after August 21 unless you know, or assume, the years involved, so too it is not possible to tell if the year 80 is before or after the year 20 unless you know, or assume, the century. If you make an assumption, and the assumption is incorrect, then the comparison of dates may be incorrect. This was the Y2K bug, or error. If the program makes an error in a date comparison, it will take an incorrect action. It may assess a late charge that is not due, or sort a list in a way that is correct according to the two-digit year, but incorrect according to the four-digit year. Avoiding the Y2K bug required shelving, modifying, or replacing programs that made that assumption.

((Embedded systems to be treated in a separate paragraph)): ( Martin | talk • contribs 20:04, 19 September 2012 (UTC))

Seems fine, except the date formats. Please see WP:MOSDATE. Also, two-digit rather than 2-digit, four-digit rather than 4-digit. It would also be good to restore the embedded systems section. --Walter Görlitz (talk) 20:15, 19 September 2012 (UTC)
I corrected the above text in line with your comments. Let's see if others comment. Meanwhile, I will look at the embedded systems discussions.( Martin | talk • contribs 01:47, 22 September 2012 (UTC))

For example, one program was written

I removed this text as personal testimony:

The problem was real in many domains, and was taken seriously by the U.S. military.[citation needed] Committees were established and substantial work was done to identify and resolve problems. For example, one program was written to locate constants of 19 or 1900, in databases. When one was found it was a trigger for a programmer to verify that it was a Y2K problem and, if so, to correct it.[citation needed]

Interesting, possibly, as an example of the irrationality of the times.
Finding an error in the code, by looking for 19's in the data would be an approach taken by only a small fragment of the industry. On the plus side, this sentence at least mentions the word database (thinking here of DL/I, or DB2, or Oracle, or Cullinane), and databases had a special "date" type of data item. The adoption of this type of format had, I believe, a relatively large impact on the Y2K problem, since dates in this format had century information.
I think the author meant to say searching the program code library for 19's triggered a further inspection. (23:19, 22 September 2012 (UTC))

First mention in 1980

The first recorded mention of the Year 2000 problem was on June 19th 1980 on the IBM Knowledge Base when Garry Jones of Extel Computing Ltd in London pointed out the FRT (File Retention Date) used to mark a file as permanent would lead to problems on January 1st 2000. On mainframes files were retained on disks with an FRT in the format yy/ddd, thus a FRT of 80/121 would not allow the file to be deleted until the 121st day of 1980 and so on. The FRT for permanent (system) files was 99/365 so a file would be retained until December 31st 1999 which back in 1980 was thought to be so far ahead nobody would need to think about it. The issue was dealt with by IBM and signed off with the comment "unsolved - not an issue in January 2000?" on 29th October 1981

I worked at Extel in 1980 and know this to be a fact. We kept a printed record of this at time but I believe it was lost when Extel moved in the summer of 1986. (I have my hand written diary from the time with the dates in). IBM deleted the source sometime in the early 90's. So all we have are hundreds of eye-witness accounts as to that post being made and IBM's response. I am Facebook friends with about 15 people who can verify this fact. My initial posting was Wiki-vandalised by "HumphreyW" as unsourced. Some facts can not be verified and if that is the requirement then 90% of Wikipedia has to be deleted because we can not prove beyond doubt that Jesus Christ existed.

We have to give credit were credit is due and I can get more people to verify the true story. I will contact them later today. — Preceding unsigned comment added by 84.217.237.42 (talk) 13:50, 8 September 2012 (UTC)

You need a verifiable source, simply saying you know it is true is not sufficient. HumphreyW (talk) 14:02, 8 September 2012 (UTC)
A few things. The first mention may have been June 19, 1980, in this article the date would be 19 June 1980. not only is the date format wrong, it would have been wrong if the American date format had been used. Similarly 29th October 1981 would be 29 October 1981. Then it's the 1990s.
Since the information was deleted, a print story would be a sufficiently WP:RS:reliable source. IBM might make a big deal about it and write something up. However, without a source, verifiable or reliable, it's just a great story, but it's not appropriate for Wikipedia.
In short, if HumphreyW wasn't removing this material, I would be and I suspect that others might just tag it after fixing the formatting. --Walter Görlitz (talk) 14:41, 8 September 2012 (UTC)
Bob Bemer first noted the problem in 1958 while working on genealogy software, and in 1971 published an article warning about the problem. Mr Barndoor (talk) 17:32, 29 November 2012 (UTC)

Requested move

The following discussion is an archived discussion of a requested move. Please do not modify it. Subsequent comments should be made in a new section on the talk page. Editors desiring to contest the closing decision should consider a move review. No further edits should be made to this section.

The result of the move request was: not moved. There's a rough consensus to reject the original proposal, and no support at all for the only specific alternative suggested. Andrewa (talk) 14:40, 4 December 2012 (UTC)


Year 2000 problem → Y2K – "Y2K" is a far more common term than the cumbersome, ambiguous term "Year 2000 problem." Comparing Y2K -wikipedia and "Year 2000 problem" -wikipedia, the former term is more common by almost ten times. Additionally, Y2K already redirects here and is used more often by our references. --BDD (talk) 19:13, 26 November 2012 (UTC)

  • Oppose – First, WP:TITLE says "Abbreviations and acronyms are generally avoided unless the subject is almost exclusively known by its abbreviation (e.g. NATO and Laser)." Second, Y2K is ambiguous, referring to the year, the bugs, the general problem, the Act, legal problems, etc., which is part of why it is so common in sources. Perhaps Y2K problem would be OK, but just Y2K, which lacks precision, etc. Dicklyon (talk) 01:17, 27 November 2012 (UTC)
    I would support Y2K problem as an alternate proposal. I have never heard anyone use Y2K to refer to 2000, though, nor anyone refer to 1000 as Y1K or 3000 as Y3K. I would also support Millennium bug as more accurate. The main problem with Y2K was thinking that it was going to be a problem. It can correctly be called a bug, because it was a programming error, that would not become an error until the year 2000. I would have to say that simply Y2K is the most commonly used term. Y2K, of course, is not an acronym, but a "numeronym", so rules for acronyms do not apply. Apteva (talk) 01:33, 27 November 2012 (UTC)
This is the established WP:PRIMARYTOPIC for "Y2K," given that the term redirects here. --BDD (talk) 16:12, 27 November 2012 (UTC)
  • "Y2K" is too short and would not be appropriate. "Y2K problem" is better. "Y2K debacle" would be best, but is unsupported and a neologism. "Year 2000 problem" is probably the best choice since it's not an abbreviation, although most people know this issue as Y2K and not Year 2000. --Walter Görlitz (talk) 01:48, 27 November 2012 (UTC)
Dick, you may have found a bunch of books that use this phrase, but you might want to rethink your proposition that it's more common than Y2K. See this This Ngram. For what it's worth, "Y2K" was apparently coined in 1995—you can see a pretty steep climb for it from there on. --BDD (talk) 00:30, 28 November 2012 (UTC)
That n-gram tells you absolutely nothing, as "Y2K" does not exclusively refer to the millenium bug. This one would be more useful. —Ruud 00:52, 28 November 2012 (UTC)
Another good comparison would be these n-grams. From Ruud's, it's very clear that "year 2000 problem" was and is a common term for the topic. Dicklyon (talk) 01:06, 28 November 2012 (UTC)
It left out Y2K. Try this one.[8] Apteva (talk) 05:04, 28 November 2012 (UTC)
"Y2K" might have been used sometimes to refer to the year, but "year 2000" is far too vague to be an effective Ngram term. Apteva's Ngram is much more relevant to the discussion at hand. --BDD (talk) 05:08, 28 November 2012 (UTC)
  • Oppose per WP:TITLE, and I agree that Y2K refers to the year rather than the problem, that Y2K was not universally used for 2000, and that as time passes fewer people will understand what Y2K refers to. Cresix (talk) 01:33, 28 November 2012 (UTC)
comment It's our job as Wikipedians to make sure that people do know what Y2K refers to, but there are alternate suggestions on the table as well such as Y2K Problem, which was the most common use of the term, and others. Feel free to read the discussion. --Walter Görlitz (talk) 01:49, 28 November 2012 (UTC)
Thank you so much for your suggestion, Walter Görlitz, and I did, in fact, read the discussion. Retitling this article isn't the only way to "make sure that people do know what Y2K refers to"; Y2K, of course, referring to the year and not the problem. Now, if you're finished browbeating me for expressing my opinion (but you're certainly not alone in the browbeating department here), I'll move on to the thousands of other discussion on Wikipedia where someone can express an opinion and not have to get it shoved back down their throat. Cresix (talk) 02:03, 28 November 2012 (UTC)
I agree that Y2K refers to the year rather than the problem Y2K means the software issue. I coined the term 12 Jun 1995 @23:31 & have a copy of the email from Peter daJager's discussion list that was focused on the software issues that began to appear as early as 1995 (5 year look-ahead) & I would assume earlier. My definition/intent has/had nothing to do with the year that's between 1999 & 2001. The only other "contender" I can still remember was FADL (faulty date logic), but Y2K is what stuck. DEddy (talk) 03:06, 28 November 2012 (UTC)
Wow, I completely forgot that you coined the term, DEddy. That was right after I coined the acronym "ROFLMAO". I'm sure you remembered me affectionately when you used my term below. Cresix (talk) 18:00, 28 November 2012 (UTC)
  • Oppose Per WP:TITLE Y2K is jargon that should be (and is) explained in the article, but not be the title. As time goes on, fewer people will automatically associate Y2K with the problem. Also our current title is parallel with Year 2038 problem, which will likely grow in importance. If User:DEddy would like to contribute his e-mail to the article, I think that would be great.--agr (talk) 12:05, 28 November 2012 (UTC)
ROFLMAO! Submit it to the Wikipedia reality distortion process? I think not. DEddy (talk) 15:04, 28 November 2012 (UTC)

Requested move, revisited

Let's stay on-topic here. There appear to be several choices as described above:

  1. move to Y2K
  2. move to Y2K problem
  3. move to something else (for reasons not yet presented)
  4. leave as is

The focus has been on the first option and has been more-or-less rejected. Is the second option similarly a non-starter? --Walter Görlitz (talk) 18:06, 28 November 2012 (UTC)


4 - Leave as is. Cresix (talk) 18:11, 28 November 2012 (UTC)
1 - Move. To say it is "more-or-less rejected" fails to consider the reasons given. Clearly the best choice. Apteva (talk) 01:51, 29 November 2012 (UTC)
Comment You obviously have not read the comments opposed. It will not be moved to Y2K as it makes no sense and has almost no support. --Walter Görlitz (talk) 01:58, 29 November 2012 (UTC)
Walter Görlitz, please stop telling other editors what they should read, what they haven't read, and what "makes no sense". This discussion is for editors to express their opinion and they don't need to be badgered for doing so. You've made your opinions clear, and that's fine, but give others an opportunity to have their own opinions without your criticisms of their opinions. Cresix (talk) 02:28, 29 November 2012 (UTC)
Yes I suppose I shouldn't just tell people that the position has almost no support, I should show them:
For 1)
Nominator and [9]
Against 1)
[10] [11] [12] [13] [14] [15] [16] [17] and me.
Sorry, and thank you for forcing me to correcting my bias. No badgering involved. --Walter Görlitz (talk) 04:23, 29 November 2012 (UTC)
Telling Apteva what he has "obviously not read" and that his opinions "make no sense" is badgering. Telling me to read the discussion is badgering. Others are entitled to express their opinions without you immediately jumping in and telling them what they have not done or what they should do. Cresix (talk) 18:24, 29 November 2012 (UTC)
I see by this edit and several others you've made that you fully understand what badgering looks like and that makes you an expert on others who do so. May we now get back to the topic? I'd be more than happy to discuss this in another forum.--Walter Görlitz (talk) 19:16, 29 November 2012 (UTC)
Yes we can get back on topic, and we can easily stay on the topic as long as you refrain from telling editors what they haven't read and referring to their opinions as "making no sense". Cresix (talk) 19:40, 29 November 2012 (UTC)
Walter, a couple of those don't belong in your list, but you're wasting your breath anyway. You can better understand where Apteva is coming from if you look at comments like this one. Dicklyon (talk) 04:29, 29 November 2012 (UTC)
4 - leave it. And yes Y2K was pretty soundly rejected. Dicklyon (talk) 03:39, 29 November 2012 (UTC)
4 - I don't know if this is an historical data point or a COI, but I wrote about it as the "Year 2000 problem," with Y2K as an abbreviation, in 1998 [18]--agr (talk) 12:27, 29 November 2012 (UTC)
  • As far as I remember I have never seen or heard it called "Year 2000 problem" anywhere at all except for this Wikipedia article. At the time, by far the commonest name was "the millennium bug". JamesBWatson (talk) 13:19, 29 November 2012 (UTC)
    It was most definitely called the "year 2000 problem", see the links I posted above. It was also exclusively called "de millenniumbug" in The Netherlands, so this could be a regional (US, Europe) difference. —Ruud 14:29, 29 November 2012 (UTC)
    Here is a contemporary example from a major US news source: [19] --agr (talk) 17:24, 29 November 2012 (UTC)
Evidently usage varies in different places, then. JamesBWatson (talk) 20:14, 29 November 2012 (UTC)
It was not a bug. A bug is something unexpected that happens. Using two digits for the year was a conscious design choice. DEddy (talk) 21:31, 29 November 2012 (UTC)
I'd suggest that to a considerable degree, it was a documentation bug. What started as a design decision became a documentation bug when no records were preserved about which bits of code contained the two-digit-year decision. Jc3s5h (talk) 22:38, 29 November 2012 (UTC)
Actually, many design decisions become bugs, when the code is exercised outside the range of previous testing. The design generally did not anticipate what the code should do in such situations, so the result was typically "unexpected". Dicklyon (talk) 22:54, 29 November 2012 (UTC)
The above discussion is preserved as an archive of a requested move. Please do not modify it. Subsequent comments should be made in a new section on this talk page or in a move review. No further edits should be made to this section.

Y2K Hardware "solutions" being sold?

In 1999 or possibly 1998 I recall watching Australian TV (one of those morning part talk / part news shows that had infomercials as part of the show), and they came on and showcased a Y2K "solution" you could buy. When you ordered, you would get a piece of hardware that looked like a serial port / parallel port adapter. You would plug it into your computer and it would magically solve your Y2K problems. I'm not sure how it worked (if it even did) but I found it interesting. I think it was a pass-through device, because, as I recall, you plugged something else into the end, but I was young at the time and couldn't remember the exact details.

A Google search finds nothing, so does anyone else have information regarding such hardware? These shows were legitimate shows (and not just infomercials that disguised themselves as talk shows) and while this may have been before the Australian government organisations cracked down on computer scams, it looked like nothing came about it, as I saw the devices on different shows for a few weeks. Grayda (talk) 02:21, 13 December 2012 (UTC)

Probably it only worked in the southern hemisphere. Dicklyon (talk) 03:16, 13 December 2012 (UTC)

Cost listed in $ and... adjusted $..?

Do we really need to compare the cost at the time to the cost in today's money? Since the value of the $ fluctuates pretty much daily in the global market, who will be updating the page that often? MrZoolook (talk) 03:58, 3 January 2013 (UTC)

It's done using a template, {{Inflation}}, so we don't have to update anything. --Walter Görlitz (talk) 04:10, 3 January 2013 (UTC)

Y2K and Global Warming - cultural legacy

The current article takes a very narrow view of the aftermath of the Y2K problem. It looks at Y2K from the perspective of those who defend and those who criticize the cost of remedial work. A more enduring legacy of the Y2K problem is the current status of Y2K in popular culture. A search which links "Y2K" and "Global Warming" registers over 5 million hits. Given the critical nature of the linkage, it would appear that a more enduring legacy of the Y2K problem is a distrust of the scientific community. In popular culture, the "Y2K bug" has become the archetypal scientific-technological scam, in which a self-serving group of experts promote a moral panic in order to attract funding to their organizations. This linkage is illustrated in articles such "It’s Always the End of the World as We Know It", by Prof Dutton, writing in the New York Times < http://www.nytimes.com/2010/01/01/opinion/01dutton.html >. Dutton argues that the Y2K problem serves a model for the analysis of other crises predicted by scientific experts, such as global warming. According to Dutton, the "increasing shrillness" of warnings about "impending catastrophe" were the product of three factors combining to create an apocalyptic culture of crisis. This crisis culture arose from a convergence of commercial interests seeking to milk the public purse, academics seeking a cause to boost their careers, and members of the public looking for an apocalyptic scenario to provide meaning for their life. Y2K has entered the popular lexicon as a metaphor for a new form of an age old phenomena - vested interests combining to promote a moral panic. Perhaps a section could be added with a heading such as "Y2K - Cultural Legacy". Asd154 (talk) 05:48, 13 November 2013 (UTC)

JavaScript getYear Method Problem

The image File:JavaScript getYear Method Problem.png is exactly the depiction of what is described about JavaScript in the "Resulting bugs from date programming" section, I have no idea why User:Walter Görlitz removed my image while keeping those sentences about JavaScript. Walter's reason is "Since the language was clearly written after 1999, it's just bad design, not Y2K". Oh, no. JavaScript and its .getYear() method were definitely designed and introduced before 1999. At least, the .getYear() method can date back to 1996 when the Internet Explorer 3 released [ref]. --Tomchen1989 (talk) 20:18, 2 May 2014 (UTC)

Not exactly since you're citing an example of IE6 which was released after 1999 and so it was never fixed. Y2K was the fix as well as the problem. Walter Görlitz (talk) 20:45, 2 May 2014 (UTC)
Yeah, in that image, "IE9+ [...]" might be "IE3 and IE9+ [...]", "IE6-8" might be "IE4-8". However because there is the .getFullYear() method as a comparison, and .getFullYear() is not supported before IE6, I had to remove IE3-5 in that image. I'll find a solution. --Tomchen1989 (talk) 21:01, 2 May 2014 (UTC)
But still, the problem was solved by recommending to use another method ".getFullYear()", and the twisted .getYear() is obsoleted but remains unchanged (as rendered in IE3) and is still supported by modern browsers for backward compatibility, it may be one of the few things that exist today which reflect the historical Y2K problem. In 2000s, even today, you may find some very old web pages which were designed only for IE4-8 that shows the problem. So to a certain extent you can say that JavaScript .getYear() Y2K problem has a long effect, which affects even after 2000. --Tomchen1989 (talk) 21:21, 2 May 2014 (UTC)

Timeline

I did some research and this is the timeline:

NN Version IE Version JS Version Implementation for getYear() getFullYear() supported? (NN/IE)
<2.0 <3.0 - - No/No
2.0 (Mar 1996) 3.0 (Aug 1996) 1.0 YEAR-1900 No/No
3.0 (Aug 1996) - 1.1 YEAR-1900 (if 19XX) or unmodified YEAR No/-
4.04 (Jun 1997) 4.0[JSNote 1] (Oct 1997) 1.2 YEAR-1900 (if 19XX) or unmodified YEAR Yes/Yes
4.06 (Oct 1998) - 1.3[JSNote 2] YEAR-1900 Yes/-
- 9 (Mar 2011) - YEAR-1900 -/Yes
  1. ^ IE had used this implementation for getYear() until IE8. However, the method might have been deprecated since IE4 and supported only for backward compatibility.
  2. ^ Since JavaScript 1.3, NN and the other browsers that comply with JavaScript specification has used this implementation for getYear(), but the method has been deprecated and supported only for backward compatibility.

Refs: [20], [21], [22], [23], [24], Javascript#Version history

So .getFullYear() was actually supported by IE since ver.4. The JavaScript stuff in Year 2000 problem#Resulting bugs from date programming is vague and not completed thus needs some expansion or rewrite. I'll find another day to do something.

Btw, quote from ECMA-262 standard: B.2.4 Date.prototype.getYear(): "NOTE: The getFullYear method is preferred for nearly all purposes, because it avoids the 'year 2000 problem.'" It's definitely a perfect example and one of the few examples that exist even today as I mentioned before. --Tomchen1989 (talk) 23:59, 2 May 2014 (UTC)

Why Blame Programmers?

Why is it programmers are blamed for Y2K issue?

How did these Fortune 500 systems get written? A bunch of programmers sitting around with a spare mainframe in the basement get together to write an accounts payable system? Something tells me this is NOT what happened.

Bogus specifications were written, given to the programmers & inadequate testing done. Programmers were PART of the problem, but certainly not the main cause. DEddy (talk) 19:33, 11 May 2014 (UTC)

I noticed that someone added a link to “List of topics characterized as pseudoscience”. This is puzzling. The computer Year 2000 issue is about technology, not science. Year 2000 (“Y2k”) failures were provable and demonstrable before, during, and after the year 2000. Y2k is unrelated to either “pseudo” or “science”. Finally, the Year 2000 simply does not appear on the list of topics characterized as pseudoscience. This is truly a random, irrelevant link.  Unician ∇  09:39, 11 June 2014 (UTC)

But it has the perception of something that was blown out-of-proportion. The see also link doesn't mean it's a part of that category, only that WP:ALSO links "do not have to be directly related to the topic of the article", but they should be explained. I'm not sure if you saw my comment, but your off-base in removing it. Walter Görlitz (talk) 15:12, 11 June 2014 (UTC)
It is perceived as something that was blown out of proportion. So the question is, would a person who is reading the article because it was blown out of proportion also be interested in pseudoscience? Alternatively, would a reader interested in events that were blown out of proportion find it reasonably easy to locate such items in "List of topics characterized as pseudoscience"? I think the answer to both question is "no". Pseudoscience is generally concerned with topics where experimental tests of the claims is impossible, notoriously extremely difficult, or the results of all such tests are subjective. While forecasts of the impact of the year 2000 problem turned out to be exaggerated, there was a massive empirical test and there isn't any substantial disagreement about the results of that test. I looked through "List of topics characterized as pseudoscience" and I was not able to locate topics where the main issue was an exaggerated forecast of the impact of a real phenomenon, nor was I able to locate any other topic where the issue was exaggeration rather than the doubtful existence of the phenomenon. Maybe one or two such topics do exist in the list, but the structure of the list does not lend itself to finding them.
In addition, "WP:ALSO" says "Editors should provide a brief annotation when a link's relevance is not immediately apparent". No such annotation was offered. Jc3s5h (talk) 16:17, 11 June 2014 (UTC)
That's the imagined connection? A perception that it was blown out of proportion? That someone somewhere once widely publicized Y2k, perhaps inaccurately, and then someone else didn't understand the problem? Wow, thank you, and I mean that seriously, that makes it vividly clear that dropping the bogus link was absolutely the right thing to do. Yes, I understand the part about “does not have to be directly related to the topic of the article”, but that link wasn't even vaguely related. “Pseudoscience” actually means something, and it doesn't mean “over-hyped”. Maybe if we had a List of often-misunderstood technology problems it would fit this article, but the deleted link doesn't.  Unician ∇  18:04, 11 June 2014 (UTC)
The fact that it was added without an annotation was mentioned in my restoration of the material and my comment above. Since the other see also is not annotated, I'll remove it for that same reason. Walter Görlitz (talk) 19:54, 11 June 2014 (UTC)
Annotations are for readers. Readers do not peruse edit histories or talk pages, so annotations don't count unless they are in the article. You added the link that had no apparent connection to the article, and failed to annotate the entry with a comment that make it apparent why it was relevant, so it was appropriate to remove the link. The other links you removed had an obvious relationship to this article, so do not require annotation. I will restore them. Jc3s5h (talk) 20:11, 11 June 2014 (UTC)
I'm sorry. You clearly don't understand what I wrote. I suggest that you read what I wrote. I am not defending the entry nor am I pillorying it. I simply stated that it should have been added with an annotation both when I restored it and in my first comment here. However, the fact that you don't see a link between this subject and the other is a second deficiency on your part. It's no longer in the article and so unless you have a salient point to make about restoring it, or a response to such a point, it might be best you if stop writing. Walter Görlitz (talk) 22:19, 11 June 2014 (UTC)

https://en.wikipedia.org/w/index.php?title=Year_2000_problem&diff=612542281&oldid=612540716 This applies to all entries. You can't show favouritism. I reverted. Walter Görlitz (talk) 22:23, 11 June 2014 (UTC)

You are basing your reverts on WP:ALSO which states "Editors should provide a brief annotation when a link's relevance is not immediately apparent...." The relevance of Y2K – World in Crisis and "Year 10,000 problem" is immediately apparent to me. Nevertheless, I have added a description to the links so that readers will have a better idea of whether the articles will interest the readers. Jc3s5h (talk) 23:08, 11 June 2014 (UTC)

simply Y2K?

The description says "or simply Y2K". Is this correct? I think is always necessary to include bug, problem or issue, by saying only Y2K you are not implying the bug but the year 2000 in general. right? — Preceding unsigned comment added by 128.79.69.223 (talk) 12:26, 11 December 2014 (UTC)

Yes. It's often descibed as Y2K. Try a Google search of only the term. Walter Görlitz (talk) 14:29, 11 December 2014 (UTC)

Y2K causing erroneous reports, leading to abortion

In the cited story for the Sheffield/Downs Syndrome error, there is absolutely nothing mentioned about abortions being performed, so until an actual source for this can be cited, the reference for "two abortions carried out" ought to be removed. — Preceding unsigned comment added by 128.230.82.27 (talk) 18:24, 5 January 2015 (UTC)

The relevant sentence in the source is "Investigators in Sheffield admitted two terminations were carried out as a direct result of the mistaken test reports." In this context "terminations" is a synonym of "abortions". Jc3s5h (talk) 18:34, 5 January 2015 (UTC)
Retrieved from "https://en.wikipedia.org/w/index.php?title=Talk:Year_2000_problem/Archive_2&oldid=1056942900"