Date:         Thu, 30 Dec 1999 13:41:15 +0000
Reply-To:     roland.rashleigh-berry@virgin.net
Sender:       "SAS(r) Discussion" <SAS-L@LISTSERV.UGA.EDU>
From:         Roland <roland.rashleigh-berry@VIRGIN.NET>
Organization: N/A
Subject:      Re: (MVS) Warning: Possible Date Problem With Change of Century!
Content-Type: text/plain; charset=us-ascii

Oh for gawd's sake. Have you only just woken up to this?

As for SAS dates then these are never stored without the 19-- part
unless you make a very special affort to do so.

Roland

RAITHEM wrote:
>
> Dear SAS-L-ers,
>
> I just chanced upon an article in a computer magazine that has stunning
> implications!  It seems that a lot of computer programmers have been using 2
> digits to store year values.  For instance, 1964 would be stored as 64, 1973
> would be stored as 73, 1999 would be stored as 99, etc.  This method saves two
> bytes per year value and makes it easy to determine the number of years between
> dates:  99 - 73 = 26.  But a problem will arise when the new century arrives and
> the two-digit years become 00!  Then, a calculation such as 00 - 73 will return
> a negative number (-73)!  So, a person born in 1973 could mistakenly be
> considered to be -73 years old!  This problem has been dubbed the "Y2K Bug."
> (Y2K stands for "Year 2000").
>
> Since there are only a few days left before the change, I would urge you and
> your colleagues to check through your own SAS programs and ensure that you are
> not using two-digit years!  If you are, then you should modify them to
> four-digit years to avoid the "Y2K Bug".  Doing this is has been dubbed "making
> an applications Y2K compliant."  I know that I will be busy in the next two days
> checking my own SAS programs and changing two-digit years to four-digit years!
> I want all of my applications to be "Y2K compliant!"
>
> Boy, am I glad that I happened upon that article!  I just hope that I will be
> able to make the necessary changes and spread the word before it is too late!
>
> I hope that this explanation proves helpful now, and in the future!
>
> Of course, all of these opinions and insights are my own, and do not
> reflect those of my organization or my associates.
>
> ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
> Michael A. Raithel, Westat
> E-mail: raithem@westat.com
> Author: Tuning SAS Applications in the MVS Environment