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

Comments

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?

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

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