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

POSIX xtime to the rescue!!!!

[dananderson]

Fortunately, some people have thought it through. There's a proposed POSIX standard, xtime, to create a new time type, and new functions, to handle a 64 bit time type (in a 32 bit world!).

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

They understood opensource advantages in 85

[prockcore]

One of the replies:

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

A design choice, not a bug

[myawn]

I worked in banking during the late 70s and early 80s, and we were well aware at the time that there was an issue with dates that would require changes to software before the year 2000.

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.

Re:UUCP?

[PatJensen]

UUCP, also known as Unix-to-Unix Copy Protocol used serial lines and dial up connections to exchange e-mails and Usenet posts, or any other type of files. It was later adapted to support live TCP/IP connections but was definitely the defacto standard for "networking". UUCP was supported on most Vax systems and Unix variants. There were even DOS UUCP stacks for offline mail and Usenet reading (look for Waffle UUCP - was quite cool back in the day).

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