Y2K-Bug in INN 1.x, 2.x

[Per Hedeland]

Katsuhiro Kondou <kondou at nec.co.jp> wrote:
>Attached will work for you.  This assumes 'YY' as current
>century.  I'll commit unless there is any problem.

>-		    yyYear = $5 + 1900;
>+		    yyYear = $5 + (yyYear - 1900)/100 * 100 + 1900;
>[etc]

While I agree that it fixes 00, and that these are the right places to
fix (and then do away with the "ensuring" in Convert() - if you dare:-),
I still don't think it is *right*: E.g. it will treat 99 as 2099, which
might actually matter for a week or so from now.

The proper thing IMHO is of course to use "closest century", a.k.a.
standard "sliding window" technique. Given all the wrong starts on this
(like adding *1900* as an y2k fix!?), I hesitate to produce any code:-),
but I believe it "should" be something like this in the "< 100" branches:

	    int tmp = $5 + ((yyYear + 50) / 100 - 1) * 100;
	    if (yyYear - tmp > 50)
		yyYear = tmp + 100;
	    else
		yyYear = tmp;

--Per Hedeland
per at erix.ericsson.se

 "Parsedate.y updates are found to actually convert any string of numbers
 or letters into a valid date in the year 2000, or on random days, a
 complete 17th century violin concerto."

  -- From Frank Durda IV's Usenet Predictions for the New Millennium

:-)