[Info-vax] 2010 date issues

[Paul Sture]

In article <xr14n.227$I8.392 at news.indigo.ie>,
 Tom Wade <nospam at picard.eurokom.ie> wrote:

> > There was a radio program the other day where a experienced computer 
> > engineer was interviewed about these kind of problems. He said that many 
> > software companies did kind of shortsighted workarounds for Y2K which 
> > are blowing up this year or anytime later. Some have blown up earlier.
> 
> I expect to see more and more of these.
> 
> Another typical 'short-cut' was where systems have a two digit field in a 
> database record for the date.  The Y2K fix involves translating between
> the 2-digit stored date, and a 4-digit display date. 
>   To do this, some cutoff is assumed, for example if the 2-digit date is < 50 
>   it is assumed 2000 
> (e.g. 2012) and if it is greater, it is assumed 1900 (e.g. 1960).
> 
> The problem is where the cutoff is chosen.  It would correspond to the oldest 
> record in the database, and since some systems store dates back as far as
> 1920 (e.g. the birth date of someone who was 80 at the millennium), the
> problem is going to repeat itself by 2020.

Tom,

This exists in OpenVMS Alpha (I don't know about IA64), and has to be 
one of the most misguided attempts ever to address the Y2K issue.

Pick any OpenVMS Alpha you want, here on V8.3:

$ dir/since=1-jan-56
%DIRECT-W-NOFILES, no files found
$ dir/since=1-jan-57

<full directory list snipped>

I'm not sure when I discovered this, but it was in the 1990s, and for me 
there was no excuse for it. VAX/VMS 7.3 still has the traditional VMS 
behaviour, which insisted on a 4 digit year:

$ dir/since=1-jan-57
%DCL-W-IVATIME, invalid absolute time - use DD-MMM-YYYY:HH:MM:SS.CC 
format
 \1-JAN-57\

IMNSHO there was no excuse for allowing a 2 digit year into the VMS date 
routines in the first place-. It simply wasn't allowed before some 
muppet decided to make it "Y2K compliant".


> What is very depressing is the speed with which most people have lapsed back 
> into 2 digit years 
> again, thus not learning the very expensive lessons of Y2K, in the mistaken 
> belief the problem won't 
> be seen again in their lifetimes.
> 

I've just noticed that in the last month.

> 
> (who actually got a support call early on 2000-01-01 about a system that was 
> reporting the date as 
> 1900, due to a patch not having been applied).

We'd been testing and fixing for the previous 2 years, so had no 
problems. Fortunately it was a weekend as well, so no great rush if 
there had been problems.

-- 
Paul Sture