RE: Y2K

I wrote:
> Here is a first go at a patch.

Ok, I found a problem already. I said:

   /* Two digit year formats assumed to be a 20th century atavism */

But then I padded the century digits of a two-digit year with code like:

        if (date[22] == ' ') { /* two digit year */
		shortdate[6] = thisyear[0];
		shortdate[7] = thisyear[1];

In January 2000, if we get process a message from late '99, received on a non-y2k system (since the crucial line is the "From " header supplied by the MTA!), this would turn it into a 2099 date.

That is, assuming the the "getlocaltime" routine isn't broken and returning 1900 for thisyear. :-) Two wrongs would make a right then.

I guess we can see why programmers tend to be the most pessimistic about the millennium bug!

In general, using "thisyear" is an attempt to recover that may or may not give the right answer. (It's used in the parse.c getfromdate routine, also.) Close to a year boundary, you may be off by one (or if processing old messages, off by more.)

We just happen to have a century, and millennium boundary coming up. (If our cultural development had been 100 years faster, we'd be talking about y19c and the "century bug," I guess.)

_____________ Hewlett-Packard Computer Peripherals Bristol Tom von Alten mailto:Tom_vonAlten_at_boi.hp.com Received on Sat 10 Oct 1998 01:58:19 AM GMT