[Info-vax] 2010 date issues

[Hein RMS van den Heuvel]

On Jan 15, 2:10 pm, Paul Sture <paul.nos... at sture.ch> wrote:
> In article <xr14n.227$I8.... at news.indigo.ie>,
>  Tom Wade <nos... at picard.eurokom.ie> wrote:
:
> > 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

:

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

Correct. It is coded up in the core SYS$ASCTIM.
Undocumented with that routine.

0 - 99 use a 2-digit year handler in there.
100 - 1600, and 10000+ are invalid
1601 - 9999 normal.

It can be seen with simple DCL like:

$ write sys$output f$cvtime("--56") --> 2056-01-16 00:00:00.00
$ write sys$output f$cvtime("--57") --> 1957-01-16 00:00:00.00

Or in any program like:

1       map (x) long bintim, long bintim_hi, string asctim=23
        while 1+1=2
          INPUT asctim
          CALL SYS$BINTIM (asctim,bintim)
          CALL SYS$ASCTIM (0% by value,asctim, bintim, 0% by value)
          PRINT asctim
        NEXT

The transition year is hardcoded in an executive cell:

$ anal/sys ...
SDA> eval @EXE$GL_TRANSITION_YEAR
Hex = 00000000.00000039   Decimal = 57

Anything above that (thru 99)  becomes 1900 + YY, below is 2000 + YY
You can poke that cell to change the transition, but the code does NOT
test a special value to make a year less than 100 invalid. That would
have been thoughtful.
Base code was added in 1991, changed to use the cell in 1992.

fwiw,
Hein.