1985 Usenet About Y2k 406
Anonymouse Cow writes "Here's a trip down memory lane (for some of you "oldsters"). Google's newsgroups has the first usenet mention of the Y2K bug... in 1985! Quote: "I have a friend that raised an interesting question that I immediately
tried to prove wrong. He is a programmer and has this notion that when we
reach the year 2000, computers will not accept the new date." Check out the replies!"
Obligatory Simpsons Reference (Score:2, Funny)
Homer: Wonders, Lisa, or blunders?
Lisa: I think that was implied by what I said.
Homer: Implied, Lisa, or implode?
Yet another Obligatory Simpsons Reference (Score:2, Funny)
Other Interesting Moments in Usenet History (Score:2, Interesting)
Sssshhh... (Score:4, Insightful)
Oh, the memories... (Score:5, Funny)
They have the nerve to say that even thoigh I have a fax machine that says it's 8/2/19102.
Re:Oh, the memories... (Score:3, Interesting)
19099 : 12,300 matches
19100 : 531,000 matches
19101 : 537,000 matches
19102 : 518,000 matches
19103 : 71,900 matches
There's a massive number of systems out there still showing April 24th, 19102 at the top of the page. That's 2 1/2 years after the bug.
Yeah, it was all a hoax and never affected any machine.
And now Y2038 (Score:5, Insightful)
Almost all of these were uttered in that Google thread from 1985 about Y2K :-)
Strangely, though, few seem to care that there are many file formats where the "automatic" kernel 64-bit date expansion they expect will be a problem. If the application expects that the date will always fit in that 32-bit field, and there's no obvious way to extend that field, then you have a lot of files which may no longer be useful...
POSIX xtime to the rescue!!!! (Score:5, Informative)
The xtime struct contains:
int_fast64_t sec;
int_fast32_t nsec;
In the 64-bit world, it's no problem--time_t is defined as a long long (64 bits).
Re:POSIX xtime to the rescue!!!! (Score:5, Funny)
Instead of following hare-brained schemes like this, I think we should look seriously at implementing RFC 2550 [faqs.org].
Re:POSIX xtime to the rescue!!!! (Score:3, Funny)
Short sighted idiots...
Re:POSIX xtime to the rescue!!!! (Score:2)
Using 64 bits for time_t is wasteful. It would be better to just use 33 bits for time_t. This would save space and push the Y2038 probably out a few more decades.
Re:3 billion? (Score:2)
the following is an excerpt from a post in the news thread:
(msd = mean solar day)
1 year = 365.2422 msd = 365 + 1/4 - 1/100 + 1/400 + error
That's why we have:
leapyear 1 out of 4
non leap year 1 out of 100
leapyear 1 out of 400 (So 2400 is a leap year.)
Read any basic astronomy book.
i'd rather head to the bar than do the math right now, so i'll pretend you did your math on a '93 pentium.
Re:And now Y2038 (Score:2)
That said, I agree with the parent that there seems to be much less concern about the problem than there ought to be. The crazy thing is how long it's taking OS vendors to supply low-level 64-bit time system calls. If I could have used 64-bit time in my stat() calls and so forth, I would have started doing it years ago. But short of not looking at the clock or writing wrappers like I did, it's impossible to code a Y2038-proof application under some OSes even today, and on the OSes where it is possible, it usually takes some hunting to figure out how. Most vendors have tweaked their system calls to allow 64-bit file sizes, but for some incomprehensible reason they didn't move to larger time values while they were breaking the APIs anyway.
Time representation is one place I think Microsoft got it right, actually. One of the Windows time formats is a floating-point value, the number of days since Jan. 1, 1900 if I recall correctly. This is great since it gives you sub-microsecond precision for the immediate future while allowing dates way off in the past or future.
Re:And now Y2038 (Score:2)
Yeah, that's a stunningly good idea. Make every date manipulation have to rely on floating point arithmetic, making things far slower than they need to be. How much did Intel pay them for that?
Are you sure you don't mean fixed point? Even that would be over the top... If you're going to be using 8 or 10 bytes to store the date (as floating point uses on Intel), then you could store microseconds with 12 bits, milliseconds with 12 bits, seconds with 6 bits, days with 5, months with 4. That's only 27 bits, leaving 25 or 41 bits for the year - slightly more than we'll ever need (even if they're signed dates with -2^79 representing millions of years BC to microsecond resolution!)
But generally, most people want the difference in dates/times, so subtracting them is usually best, so I'd say that just using a 64 bit integer is more than adequate.
I think the worst example of using bitfields are Microsoft's date formats in MS-DOS. The bitfield format makes doing any calculation far more complicated than is really necessary, and only provide 2 second resolution. It does allow dates up to 2107, though fortunately I'm going to live safe in the knowledge that no-one in the civilised world will still be using DOS then (unless 640k really is enough for someone.
Re:And now Y2038 (Score:4, Informative)
Go see the list of critical dates (Score:3, Interesting)
Anyway, Stockton's page had me occupied for a few good hours. It's quite a read. It has great stuff on it, like the base filedate for Windows "Last Modified" calculation, when 16-bit BSDs die, when NTFS fails, etc. LOTS of good dates there.
I even submitted my newly-discovered UNIAPI_TIME epoch value. It was much more exciting that submitting my transmeta-based Gateway/AOL Webpad's BogoMips value to the BogoMips mini-HOWTO [tldp.org].
-B
Re:And now Y2038 (Score:2)
Hmmm. The conflicted mind (Score:3, Funny)
Ahh the conflicted mind
Re:Hmmm. The conflicted mind (Score:5, Funny)
Them: Hello?
You: Someone who worked in that office in 1985 posted to usenet about the Y2K bug!
Them: So?
You: Ummmm...Is your refrigerator running?
Them: *click*
-B
Re:Hmmm. The conflicted mind (Score:2)
Sure, but if I'm thinking this, so are 1000 other people. We could slashdot the phone system for a little fun.
hehe. Yes evil thoughts.
Ah the good old days. (Score:4, Funny)
Looking back at it maybe we should have killed it while it was young.
Re:Ah the good old days. (Score:2)
Re:Hmmm. The conflicted mind (Score:2)
That was before the Great Renaming.
Brilliant!...... (Score:4, Insightful)
Bug fix strategy for date roll-over...quoth message...
"First, I modified the daily demand deposit program with code that checked for the date and about mid-1979 started printed warnings on the console of what would happen come new year. Then the systems analyst and I got new jobs. This is known as stepwise interactive development."
It's funny to see that this problem was known at least 30 years before the Y2K hysteria....I hope that this is a lesson to all of you young programmers....
"run away!...run away!..." Holy Grail...
Re:Brilliant!...... (Score:2)
I used to think only web masters would find a difficult problem, then make it somnebody elses problem.
Re:Basic mathematics (Score:2)
The discussion happened well before 1979, close enough to be considered almost 30 years ago. I'm sure he wasn't the first person to think about the problem.
Re:Basic mathematics (Score:2)
Old news! (Score:3, Funny)
reading old usenet posts (Score:5, Insightful)
Just some ramblings...
Re:reading old usenet posts (Score:5, Funny)
Shut the fuck up, asshole. If I wanted your opinion, I'd give it to you. Now you either fuck off, or I'm gonna smack you.
cum-bubble!
Re:reading old usenet posts (Score:5, Funny)
Re:reading old usenet posts (Score:2)
Actually, what really takes me back is the email addresses. Notice that everyone just uses them? No mangling, no spam buckets, no nada. There isn't even the THOUGHT they would be abused. The thought sure never occured to me back in those days either - sigh.
You know what I think makes the difference? (Score:5, Insightful)
It's the same reason why bumping into someone while walking will lead to "excuse me" and "s'okay", but cutting someone off in traffic will lead to an angry honk and possibly tail-gating for the next several minutes.
mark
Re:reading old usenet posts (Score:2)
Not to stereotype but A lot, if not most
fools (Score:3, Funny)
Oh wait, that didn't happen...I gotta go find that money I buried.
Not much to worry about now.... (Score:2)
FYI just announced today...Cool NERD clothing!!! [cafeshops.com]
Old news (Score:5, Interesting)
http://www.google.com/googlegroups/archive_announ
There's some really great ones in there, including Linus announcing Linux, Microsoft soliciting for new 'wizards', a thread about the chernobyl accident, and so on.
Re:Old news (Score:2)
I wish Lucas & Co. would get the thing going a little faster. I can't really imagine waiting until 1997 to see all nine parts of the Star Wars series.
Heheh.. The other funny thing is that the post is by Randal Schwartz of Llama and Camel book fame. Hang in there Randal, you've almost made it to Episode 6! :)
$$$ (Cash) (Score:2)
Absolutely fascinating (Score:2, Insightful)
Human nature: ignore problems until you can't.
My nature: fix problems now, you'll be happier in the long run.
My fate: get treated as a doomsayer/whiner.
There is a cost to being proactive...
On not doing anything about a problem (Score:2)
Business decisions are not made by engineers; they are made by the people who employ engineers.
Business people with short term profit motives should not be confused with engineers having made or not made a decision to deal with the Y2K problem.
UNIX currently faces a Y2038 problem with 32 bit signed seconds since the epoch, yet I don't anyone paying people proactively deal with that problem; do you?
-- Terry
What would really be cool... (Score:2)
Oh well, I'm looking forward to dealing with 2038 myself. What is it? About mid Janurary when it dies?
Re:What would really be cool... (Score:2, Informative)
The software was for an archialogical database and stored the year photos were taken as 2 digits, while other data was stored in a 5 digit year field representing BC, AD or BP. BP related to carbon dating and is the number of years before 1950. 1950 is 0 BP.
It really was an odd piece of software.
Re:What would really be cool... (Score:2)
15 years and... (Score:2, Informative)
This is Usenet?!? (Score:5, Funny)
But where is all the off-topic spam? Where are the trolls? Where is the porn? The flamers?
This is clearly some sort of clever mock-up of Usenet and not the real thing. Frankly, given the omissions I've stated above, it's not even a very well-done imitation; I'm shocked the /. boys would be fooled by it.
Re:This is Usenet?!? (Score:5, Interesting)
ahh 1985 (Score:4, Funny)
Seriously, just LOOK at those posts. Proper grammar, proper punctuation. Hell, one guy even INDENTED the first line of a paragraph! Have you ever SEEN such madness?
Um yes. Remember this article.... (Score:2)
Scroll down to 1985.
er... (Score:2)
Love that old email address (Score:2)
bolles@reed.UUCP -- uucp
Also notice, if you try to check out the cross linked posts..
Group: net . bugs (This group is no longer archived)
Group: net . flame (This group is no longer archived)
Group: net . puzzle (This group is no longer archived)
wrong :) (Score:4, Informative)
My favorite post (Score:3, Flamebait)
Some software blows up on dates at other times. I'm aware of some old
DEC software (don't worry... you're NOT using it... it's single user!)
that keeps the date year as a 5 bit offset from 1972. Let's see...
1972+31=2003, so it blows up in 2004. Probably, tho, the display-a-year
routine isn't written to handle beyond 31-dec-99, since no one expects
that RT11 (oops, now I said it) will still be used then. I hope.
---------
Join the (Hopefully) Great Usenet Blackout 4/11/1985
Alright, so maybe that wasn't in there. But wouldn't it just suck if someone 15 years from now posts a story about a 15 year old slashdot post to a huge newsite and all the people laugh at what huge dorks we were?
Re:My favorite post (Score:2, Insightful)
I love this one (Score:2)
on tape and on disk
They understood opensource advantages in 85 (Score:5, Informative)
"If you are really worried about timewrap breaking programs in subtle ways,
then set your clock ahead now, and find the bugs. That will give you several
years to fix them. If you are binary only, you might NEED several years
to get you vendor to fix them!"
See! Even in 1985, they understood that opensource bugs get fixed faster than properietary software!
my favorite reply (Score:5, Insightful)
How prescient some people were back then :-)
Google Award (Score:2)
Attitude (Score:4, Interesting)
Not that there's anything wrong with that attitude, but it does indicate two things: One, that even hardcore geeks (i.e. people who had email addresses in 1985) can be complacent about things that seem a long way off (rather than fixing it long before it'll become a problem, as would be "ideal", for suitable definitions of ideal); and two, that computers were not the societally pervasive force that they've become in the last decade. A lot of the reason people didn't see the Y2K bug having that much potential impact that far in advance was because this kind of omnipresence of computers was just beginning. (In AD 1985, personal computerization was beginning...) These days, even an average Joe on the street would probably be astonished to hear that any kind of, say, large utility wasn't thoroughly computerized, but in 1985, such a revelation would have been met with mostly blank stares.
I feel old now (Score:2)
Randal L. "Perl Jedi" Schwartz? (Score:4, Informative)
How cool is that? He even scores for quintuple Nerdhood by:
1. Being on Usenet in 1982
2. Having his Usenet post on Google's memorable postings list
3. Being a Star Wars geek
4. Being a Star Wars geek ON Usenet, IN 1982!
5. Writing his own scripting language
And who knows, maybe that page at Google was generated by HIS scripting language
Re:Randal L. "Perl Jedi" Schwartz? (Score:3, Interesting)
Guess I should've stayed in Python Land, where both the newbie books and the language are written by the same old Guido.
Check out this post about Slashdot in 1985 (Score:2, Funny)
Slashdot: Are you planning to read Slashdot on August 17th 2002?
Users: Probably not - it's a Saturday.
Slashdot: Well if you do, whatever you do, don't read Slashdot on August 17th! The internal coding of "August 17th 2002" triggers a perl script that sends Cowboy Neal's entire Boy Band mp3 library to your e-mail account...
what was missing... (Score:2)
seriously though, i think it was interesting that the majority of their discussion seemed to be focused around the fact of calculating whether or not 2000 was a leap year, rather then the fact that computers couldn't handle the year 2000 because they were only storing the last two digits representing the year, and not the century...
also, noticed there was a lack of links to the "goatse.cx" website in the thread...
Another missed opportunity (Score:2)
Just think that in a few years you will be able to refer to the year 2002 as aught-two! By the way the Websters Thesaurus also lists ought as an alternate spelling to aught.
Yikes. The year is more than half over and I don't find this out 'til now. So much lost time!
-a
Most telling quote from that thread (Score:2)
year 1995, if only so that the society on which they depend for profits
will continue to exist.
"
Ironic posts.. (Score:2)
Someone makes a point, "From cold fusion it's not a far step for 750 terrorist cells to begin making H-Bombs in their kitchen"
Ironic that the H-Bombs are available first, eh?
A design choice, not a bug (Score:5, Informative)
People seem to think that this was some unexpected oversight; it was nothing of the sort. Given the cost of storage at the time, and the millions of records that had to stored with one or more date fields, it was a purely economic decision to save money at the time. I don't have the numbers needed to do the math, but I suspect it was actually the right choice. If you compare the cost of additional required storage to the eventual rework cost, discounting for time, maybe it doesn't look so stupid. Especially since many programs really did cease to be used before the problem arose (although probably far fewer than we would have predicted)
We all joked at the time that, along about 1998 or 1999, we would take jobs in other industries until the changeover was complete.
1st Dance Dance Revolution Mention... (Score:2)
http://groups.google.com/groups?selm=85%40nixbln.
Talk about a revolution.
Any net-detectives out there? (Score:2, Insightful)
A who? (Score:2)
Subject: Re: Computer bugs in the year 2000
Newsgroups: net.bugs
View this article only
Date: 1985-01-24 10:05:00 PST
Another problem is that we have gotten into the habit of only using the
last 2 digits of the year (look at your checkbook). Even worse is that
some business software only allows a 2 character wide field for the
date. Perhaps the designers did not expect their program to be in use
in the year 2000 but I would not be suprised to see a considerable
amount of 370 code running in the year 2000.
Just think that in a few years you will be able to refer to the
year 2002 as aught-two! By the way the Websters Thesaurus also lists
ought as an alternate spelling to aught."
Say what? aught-two ?? Anyone here calls it aught-two ??
Bob Bemer (Score:4, Informative)
R.W.Bemer, "What's the Date?", Editorial, Honeywell Computer J. 5, No. 4, 205-208, 1971
Here is a funny quote from him: He has a rather impressive list of accomplishment to go along with those tidbits, including prior art [bobbemer.com] for the British Telecom patent fiasco [techlawjournal.com].
A pretty neat dude.
Signal to Noise (Score:4, Funny)
y2038 (Score:3, Informative)
char timebuff[4];
*((int*)timebuff) = time(NULL);
Instead we do stuff like this:
time_t timebuff;
timebuff = time(NULL);
When the system type for time_t is change to something with more than 32 bits, the code just needs a recompile and voilla - it handles dates past 2038. The work is going to be in making sure every program gets recompiled, and in converting saved files that have the date already stored in 32 bits. The ugly part will be if your system depends on third-party stuff in binary form only that you can't upgrade for whatever reason.
Note, I didn't say the problem will be nonexistant, just that it will be easier to fix than y2k.
Early open-source advocate? (Score:2)
If you are really worried about timewrap breaking programs in subtle ways,
then set your clock ahead now, and find the bugs. That will give you several
years to fix them. If you are binary only, you might NEED several years
to get you vendor to fix them!
hmm (Score:2)
It was the 70s, remember.
back-in-the-day-life-was-great dept. (Score:4, Interesting)
Here we see a Usenet thread, with thoughtful and interesting responses from knowledgeable, experienced people at universities and research institutes. No flame wars, no snot-nosed kids from AOL, no spamming, no hot grits or Natalie Portman, no ranting about how Usenet is a mysterious cabal of Illuminati scheming to rob our freedoms and kill our firstborn.
I wasn't around in the nerdy, cliquish days of 1985 (I'm not that old!), but I did see the early 90's -- when Usenet was still a respectable hangout for serious and informative disussion -- dissolve into the mid 90's -- when all hell broke loose. It was exciting, and only logical, to see such a useful medium become so popular, but now the spammers and ranters and schemers have completely taken over. There are still a few pearls in there these days, but you have to go look for them in that enormous, stinking pile of shit.
I used to use the 'vi' binding in 'nn', which gave me a full curses screen to type my posts. Now I type Slashdot comments in this puny little HTML textarea. What has the world come to?
Re:not Y2K but.... (Score:4, Informative)
Re:not Y2K but.... (Score:2, Funny)
Re:not Y2K but.... (Score:2, Funny)
I did too, but it wasn't a waste. I robbed all the suckers that were withdrawing all their money!!
Re:not Y2K but.... (Score:2)
On y2k, I was at a friend of mine's house. When midnight rolled around, the power went out.
Turns out, her brother ran to the fuse box and threw all the switches. So yes, y2k did cause a power outage.
Shouldn't be a problem (Score:2)
Re:Shouldn't be a problem (Score:2, Interesting)
Re:Shouldn't be a problem (Score:4, Insightful)
And how many bits is that integer number? And what is the base used? 32 bit Unix rolls in 2038.
Rollover will always be a problem somewhere along the line. Hopefully, a 64 bit date field will be good enough until computers themselves are obsolete (over 584 million years at a resolution of 1 ms).
Further, there are ASCII dates hanging around, look at all the perl webpages or the programming language MUMPS which is probably holding your medical record information somewhere.
Re:not Y2K but.... (Score:2)
I think it's Y10K that's going to be the REAL ball-buster. How many systems out there are using 5 digits to store the year???
I'm laying in my emergency supplies right now!
2400 *IS* a leap year (Score:4, Informative)
Err...no, 2400 IS a leap year!
To review:
2000: leap year
2100: not a leap year
2200: not a leap year
2300: not a leap year
2400: leap year
Re:Back to the future (Score:5, Interesting)
While it's a fairly trivial task to make the actual corrections to the programs, it most certainly was not a trivial task to:-
1) Make sure that EVERY y2k bug was identified
2) Recompile/retest/re-rollout many thousands of affected programs.
3) Persuade all suppliers/customers/trading partners to fix the systems.
In the end, the world didn't end *because* we had pulled out the stops and fixed the bugs. It's worth noting though that examples of every type of predicted failure did actually occur.
The originating article here dates from 1985 - the problem had been identified with 15 years to go. Why were non-compliant PCs still being built in 1997? Why were software houses *still* producing non-compliant code in 1995?
Re:Back to the future (Score:2)
Re:ahh the thoughts (Score:4, Funny)
I guess it wouldn't work in that direction, though.
Re:ahh the thoughts (Score:5, Funny)
I guess it wouldn't work in that direction, though.
Of course not. Their news reader app cannot handle the four digit year....
Re:Interesting but... (Score:2, Insightful)
Re:I wonder.... (Score:2)
And that other one about that crazy geek that modified his computer case for no reason other than it looked cool. I'll be telling that story to my grandkids.
-B
I know... (Score:4, Funny)
Re:September 10th (Score:2)
Re:Henry Spencer (Score:2)
-a
Re:Henry Spencer (Score:3, Informative)
Re:Henry Spencer (Score:2)
Re:Google timeline (Score:2)
Re:Wow, people had real conversations back then. (Score:2)
Re:UUCP? (Score:5, Informative)
To exchange information to other hosts, before protocols like DNS became mainstream there was a public Systems repository. The addresses indicated showed the path that a mail or post would take before it would be delivered. A single post make take 5 modem calls between hosts at varying times of the day (depending on long distance costs) before it would show up. It definitely wasn't as fast as it is now over a live TCP/IP network.
I still believe that some newspaper wire companies and stuff still use UUCP to dial up and move news articles. UUCP was cool for its time. As much as people clamored for lots of bandwidth and a nice static IP, it was cool enough just to BE a UUCP node. UUCP was much like later protocols like FidoNet - but UUCP used Arpa compatible mail headers so it could be used for sites that had live Arpa network connectivity.
Anyways, hope that helps. You old-timers that know more then me feel free to correct me. I'll go back to listening to the Dodgers Game.
-Pat