1985 Usenet About Y2k

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

Sssshhh...

[jukal]

Yeah, the developers already back then knew that they planted a ...krrrhmm... a few little easter eggs, but we don't want to be unemployed... do we?

If you listen to people today

[Anonymous Coward]

They act as if the Y2K issue was completely made-up and unworthy of fixing because nothing broke when it rolled around. HELLO? Nothing broke because things got fixed beforehand. People are really dumb.

Thank you, Anonymous Cow

[CrazyDwarf]

This was really an interesting read. I really appreciate Anonymous Cow going to the effort of finding this and posting the location for us all to peruse.

And now Y2038

[shoppa]

Many of today's programmers are curiously nonchalant about Y2038, when Unix and other OS's that store the date in number of seconds since 1970 in a 32-bit signed quantity overflow and the date goes negative. The vast majority lump it into the somebody else's problem category, for one of several reasons:

• They won't be around.
• Surely the date field will expand to 64 bits by then.
• They plan on making a lot of money 36 years from now

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

Brilliant!......

[Dr_Marvin_Monroe]

I've always suspected that people in 1979 were smarter than today, and NOW I have proof!

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

reading old usenet posts

[Jafa]

Man, I love reading these old threads. It's always a cool bit of memory lane, seeing the old email addresses (UUCP, ARPA), and the old but still familiar sigs. And the coolest thing is the lack of flames. When the one person in the thread who was an astronomer made a mistake on leap years, no one jumped at his throat. One person even says "So, he made a mistake. Who doesn't?" That would never happen that nicely today.

Just some ramblings...

Re:Interesting but...

[sys$manager]

It's called nostalgia...

Absolutely fascinating

[tuxlove]

These guys obviously had a grasp of the problem and understood how to avoid date problems in the future. They also understood the devastation that could ensue if dates were to go awry in software. But, as is human nature, did any of them do anything about the problems? I guess not, since 15 years later everyone was in a panic about Y2k. One guy even quit his job rather than fix a serious pending date problem in his system.

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

my favorite reply

[elmegil]

I think, though, that IBM will get moving on this problem around the year 1995, if only so that the society on which they depend for profits will continue to exist.

How prescient some people were back then :-)

Re:Shouldn't be a problem

[kallisti]

No one stores dates in 'ascii' format anymore. They are usualy stored as integer numbers representing a number of seconds after an offset.
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.

You know what I think makes the difference?

[Dephex Twin]

Anonymity. Most people at that time used their real identities, and the community was smaller and simpler, so it would be harder to hide.

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:My favorite post

[HaeMaker]

People are laughing now.

Any net-detectives out there?

[swfranklin]

I think it would be interesting to track down some of the participants from this thread (particularly Spencer L. Bolles, the originator) and get their viewpoints 17 years later.

You are wrong

[Anonymous Coward]

That was the first discussion on Usenet.

It had clearly been discussed before. But not on Usenet. (For instance in 1975 Usenet didn't exist to discuss it on.)