Date: Tue, 5 Jul 2005 18:11:52 -0400
Reply-To: Venky Chakravarthy <swovcc@HOTMAIL.COM>
Sender: "SAS(r) Discussion" <SAS-L@LISTSERV.UGA.EDU>
From: Venky Chakravarthy <swovcc@HOTMAIL.COM>
Subject: Re: validating dates
I should have mentioned in my previous message that I used YEARCUTOFF =
19900 for my example.
Toby, the documentation should make no assumptions about *only* the data
step being able to use it (SQL can too). I guess this is a left over from
pre-SQL era.
The second thing I was implying was that they should revise the statement
about the range of dates which currently reads 1582 - 19900. If my example
stands, this should be restated as 1582 - 19999. Of course, all of this
would ensure that some N generations later, there is a DUNN programming
correctly for a date calculation :-).
Venky
On Tue, 5 Jul 2005 20:51:27 +0000, toby dunn <tobydunn@HOTMAIL.COM> wrote:
>Venky,
>
>Yeah it looks like tghey could have said one can adjust the yearcutoff
>option that a datastep uses by doing the blah blah blah rather than what
>they came up with. I wish they SI would take the line that the written
>documentation (with out the examples) should stand on its own and the
>examples should just be there as icing on the cake.
>
>
>
>Toby Dunn
>
>
>
>
>From: Venky Chakravarthy <swovcc@HOTMAIL.COM>
>Reply-To: Venky Chakravarthy <swovcc@HOTMAIL.COM>
>To: SAS-L@LISTSERV.UGA.EDU
>Subject: Re: validating dates
>Date: Tue, 5 Jul 2005 16:44:36 -0400
>
>I think the documentation on the range that SAS can handle, needs some
>restating. The following demonstrates that SAS can read beyond 19900 and
>perform some minor calculations.
>
>102 data _null_ ;
>103 x = input("31dec99",date7.) ;
>104 y = input("31dec97",date7.) ;
>105 z = intnx ( "year" , y , 2, "s") ;
>106 put x = : weekdate. y = : weekdate. z = : weekdate. ;
>107 run ;
>
>x=Monday, December 31, 19999 y=Saturday, December 31, 19997 z=Monday,
>December 31, 19999
>
>Sorry, I don't have a method for verifying the accuracy of the weekday :-).
>
>On the other hand, the documentation may actually be referring to the range
>of the YEARCUTOFF option (1582 - 19900). The first year of the 100 year
>span is 19900, so dates can be input all the way to the last day of 19999.
>Even so, parts of the YEARCUTOFF documentation are equally baffling.
>Consider:
>
><<<
>Note that while the default value of the YEARCUTOFF= option in Version 8 of
>the SAS System is 1920, you can adjust the YEARCUTOFF= value in a DATA step
>to accommodate the range of date values .......
> >>>
>
>This is poorly worded, leading to the impression that one can usefully
>change the system option within the data step. Yes, the example that
>follows provides some clarity where the option is set prior to the data
>step and not within. Then again, one can argue that SQL should be able to
>use it too.
>
>Venky Chakravarthy
>
>On Tue, 5 Jul 2005 09:48:48 -0400, Howard Schreier <hs AT dc-sug DOT org>
><nospam@HOWLES.COM> wrote:
>
> >See code below. I think you are mistaken about 31.09.2005.
> >
> >01.01.21000 is a complicated case. When you compress out the dots you are
> >left with 9 characters (010121000). So if you process that with DDMMYY8.,
> >it will ignore the last zero and extract 1 January 2100, which is valid.
> >
> >When you increase the width of the informat, SAS has to guess where the
> >implicit delimiters are (010 12 1000 vs 01 01 21000). In this case, both
> >are out of range and yield missing values for the date. By the way,
that's
> >something you could have determined yourself from the documentation,
which
> >states "SAS can perform calculations on dates ranging from A.D. 1582 to
> >A.D. 19,900." See
> >
> >Base SAS
> > SAS Language Reference: Concepts
> > SAS System Concepts
> > Dates, Times, and Intervals
> >
> >To better see what's going on, try 01.01.19900. It's valid, but the
> >extracted date is 10 November 9900, telling us that 010119900 is
> >interpreted as 010 11 9900 rather than as 01 01 19900. This leads to what
> >is probably the most important point: Why eliminate the dots? They can
>only
> >help. In other words, get rid of the COMPRESS call and widen the informat
> >to accommodate:
> >
> > datevalue=input(date_values, ddmmyy11.);
> >
> >Then you will get the date value 1 January 19900. Interestingly, you
>cannot
> >display it with the DATE format, which has a maximum width of 9. So even
> >though SAS can store date values out to the year 19900, not all of the
> >tools support that full range. SAS is not fully Y10K compliant.
> >
> > data _null_;
> > date_values = '31.09.2005 ' ;
> > datevalue=input(compress(date_values,'.'), ddmmyy10.);
> > put date_values = datevalue= date9.;
> > date_values = '01.01.21000 ' ;
> > datevalue=input(compress(date_values,'.'), ddmmyy10.);
> > put date_values = datevalue= date9.;
> > date_values = '01.01.19900 ' ;
> > datevalue=input(compress(date_values,'.'), ddmmyy10.);
> > put date_values = datevalue= date9.;
> > datevalue=input( date_values , ddmmyy11.);
> > put date_values = datevalue= date9.;
> > put date_values = datevalue= weekdate.;
> > run;
> >
> >On Mon, 4 Jul 2005 08:45:02 -0700, =?iso-8859-1?q?Rune_Runnest=F8?=
> ><rune@FASTLANE.NO> wrote:
> >
> >>Thanks. It seems to work almost fine. The only weekness is that it
> >>accepts '31.09.2005' as a valid date. But september doesn't have more
> >>than 30 days.
> >>
> >>I think I would prefer to capture the valid and not valid values in a
> >>dataset, instead of in the log. It's more practical for the further
> >>reporting when the number of not valid values become many thousands
> >>records large.
> >>
> >>As far as I have tested, the following code will do well:
> >>
> >>data not_valid (drop = datevalue)
> >> valid (drop = datevalue);
> >> set dates;
> >> datevalue=input(compress(date_values,'.'), ddmmyy10.);
> >> if date_values ne '0000000000' and
> >> date_values ne '' and
> >> datevalue = . then output not_valid;
> >> else output valid;
> >>run;
> >>
> >>I experienced that when writing ddmmyy8. in the input where the column
> >>datevalue is created, I got the date '01.01.21000' as valid, but when I
> >>changed to ddmmyy10., then it belonged to not_valid. I am not quite
> >>sure what is right or wrong, can a date value in SAS be as hight as
> >>'01.01.21000' ? Neither do I understand why I get this difference in
> >>result when changing the date informat.
> >>
> >>Regards
> >>Rune
| 
