Conference evms::y2k

    Windowing solutions in general
    ------------------------------
    
    As we know the year is stored as two digits
    
           '00 '01 '02 ..... '50 .......'97 '98 '99 
    
   So if we pick a year eg. '50
    
    with an appropiate conversion routine a two digit year becomes a 
    four digit year.
    
           '00 '01 '02 ..... '50 .......'97 '98 '99 
          2000 2001          1950      1997 1998 1999
    
    we can also slide the pivot date, with a smarter conversion routine, 
    so we can always look 50 year into the future, no next year we can choose
    '51, the year after '52 etc. Data older than 50 years will need to be 
    deleted as the pivot date is changed. You can write your own code or
    buy a ready made library, from a software vendor, to allow you to do 
    date conversions.
    
    
    Advantages:
    
    Our data get to remain exactly the same. (Good for our 1,000,000 record
    billing database, no need to expand the date fields)
    
    
    Disadvantages:
    
    1) We now need a conversion routine, because, we still must work with four
       digit dates to allow comparisons and to display to the outside world.
    
        convert_YYMMDD(00/01/01) gives 2000/01/01
    
        If date_YYYYMMDD > today then ....
    
       and a we need similar reverse conversion routine to store new
       digit dates as two digit data.
    
    2) All two digit data occourance must be located and 'treated'. 
    
    3) If we send our binary data to someone else they must know/use the same
       date conversion routines.
    
    
    Given the above disadvantages, in situation where data field
    expansion does not cause big problems, it is probably better
    just to go ahead and expand the data field. It keeps everything
    simpler.
    

   The variation on this `pivot' scheme is the `transition' year scheme.

   The OpenVMS Alpha value for the transition year is `57', and this value
   is available in the data cell EXE$GL_TRANSITION_YEAR.

   Values of less than 57 are assumed to be 2000+value, while values larger
   than 57 are assumed to be 1900+value. 

   I'd agree with the conclusion of the previous reply: expand the field
   whenever possible.

A transition year of 57 seems incredibly Digital-centric.  Wouldn't it
have been better for all vendors to agree on the same transition year,
such as 50?

It makes sense to read the transition year from a standard location
instead of hard coding it, so that it can be changed later (e.g. in 2045
or so it might make more sense to use a transition year of 00).  Is there
a way to read the transition year from a non-privileged program?

				-- Bob

>A transition year of 57 seems incredibly Digital-centric.  Wouldn't it
>have been better for all vendors to agree on the same transition year,
>such as 50?

  Hey, why shouldn't *Digital* lead the way in defining the "standard" once
  in a while? What year was Bill's birthday?

  "all vendors" don't even agree there's a *problem* at the moment, let alone
  agree on a solution.

>Is there
>a way to read the transition year from a non-privileged program?

  There may be a user callable API somewhere, but I can't find it. The 
  location is readable from usermode though. For V6.1 and V6.2, it's the
  same address:

SDA> eval exe$gl_transition_year
Hex = 808062E8   Decimal = -2139069720          EXE$GL_TRANSITION_YEAR

  hence:

$ EXE$GL_TRANSITION_YEAR=%x808062E8
$ a=f$fao("!@UQ",EXE$GL_TRANSITION_YEAR)
$ show sym a
  A = "57"

  For V7.1 it's moved:

SDA> eval exe$gl_transition_year
Hex = FFFFFFFF.81407078   Decimal = -2126483336         EXE$GL_TRANSITION_YEAR
SDA>  Exit
$ exe$gl_transition_year=%X81407078
$  a=f$fao("!@UQ",EXE$GL_TRANSITION_YEAR)
$ show sym a
  A = "57"

  This should also be possible from most HLLs, provided you LINK/SYSEXE.

						John Gillings, Sydney CSC

    don't trust those addresses, they move around quicker than you can
    think off
    
    Symbols sorted by name
    ----------------------
    EXE$GL_TRANSITION_YEAR          = FFFFFFFF.82D07278 : 00000000.00000039
    
    this is from my Alpha box
    
    /cmos

A transition year of 57 is not only Digital-centric, it is very VMS-specific.

A little background may help, although the point is valid - as are the 
suggestions about the availability of the transition point.  Originally, 
EXE$GL_TRANSITION_YEAR was implemented to support the translation of the year 
field in the Alpha BBW; the Dallas chip only allows 2-digits and we had to 
zero-base it to get the leap-year to work correctly for 2000.  It wasn't
originally intended to act as a sliding window technique for Y2K, but it
was tied to the 2-digit support in $BINTIM that had been previously added
and it propagated from there to most of our applications.  Originally we
considered going with the Unix Epoch of 1970, but decided that, in the place
of any industry standard, erring on the side of caution and go with the date
that was the earliest anyone was likely to have a Digital time-stamp.  1957
was a guess and seemed like it gave us a reasonable amount of time to get
the watch chip replaced in the Alpha architecture. 

With Y2K, I agree that a hard-coded value is not a good idea, and our value
may shift with some emerging standard - if there ever is one.  I also agree
that there should be system-wide accessibility and potentially some level
of control on a node basis.  Both of those are in the Y2K-compliancy release
planning stages; if it is possible and worthwhile, I'll try to backport them,
too..

-Jim

re .4
    
    nit...
    
>$ a=f$fao("!@UQ",EXE$GL_TRANSITION_YEAR)
               ^
               L

Re: .4

>  This should also be possible from most HLLs, provided you LINK/SYSEXE.

Linking with /SYSEXE isn't a good idea for layered products that have to
run on multiple versions of OpenVMS.

Could this be added as a $GETSYI call?

				-- Bob

:>  This should also be possible from most HLLs, provided you LINK/SYSEXE.
:
:Linking with /SYSEXE isn't a good idea for layered products that have to
:run on multiple versions of OpenVMS.

   This one is a no-brainer to avoid -- one can have the product startup
   rebuild a single near-stub component shareable image that fetches this
   value out of system space, and that uses a default near-stub that uses
   `57' should the link fail for any reason.  Component images are linked
   against this shareable image.

:Could this be added as a $GETSYI call?

   Sure.  Toss a QAR into the pipe.  (This cell, or an emulation, would also
   need to be added on OpenVMS VAX.)

    re: .3
    
    Please note the '57 is not that DEC Centric as the first satelites
    were launched in that year.  Thus some non-DEC folks (trekies?) will
    start counting in 1957 as the first year in space.
    
    Don