Prev: Which to use, SAS or SUDAAN?
Next: PROC OPTMODEL: does it solve Mixed Integer Programming problems?
From: Arthur Tabachneck on 16 Jan 2007 20:02
Ya,

I'm not sure if the following was the original post from Paul that you
were referring to: http://xrl.us/uao4

Regardless, I was testing out some possibilities regarding invalid dates
and discovered that all of the following work:

data have;
input thedates mmddyy10.;
format thedates date9.;
cards;
10/5/2OO6
1/14/2XY4
12/2/9BB5
12/3/2XX3
;
run;

proc print data=have noobs;
run;

05OCT2002
14JAN2002
02DEC2009
03DEC2002

Interestingly, as long as the first and fourth character of the year are
digits, if the four characters together don't represent a valid number,
then SAS will return the first character+2000 as a valid year.

Sure sounds like a bug that needs quick fixing!

Art
---------
On Tue, 16 Jan 2007 12:15:59 -0500, Ya Huang <ya.huang(a)AMYLIN.COM> wrote:

>Hi there,
>
>I used to test if a character date is valid by testing with
>a input function. If after input function I get a nonmissing value,
>then the character date is valid. Until I saw a post by Paul Dorfman, a
>while ago, showing that this is very dangerous:
>
>data _null_;
>a='25MAY2OO6'; /* note here is OO, not 00 */
>d=input(a,date.);
>put a d date.;
>run;
>
>25MAY2OO6 25MAY02
>
>Now I'm wondering what else I can do to test if a character date
>is valid without V9 funcy function, since I'm still using v8.12.
>Another assumption is that character date is like DDMMMYYYY.
>
>Thanks
>
>Ya
From: Mike Rhoads on 17 Jan 2007 08:33
Scott,

This seems odd to me as well.

INPUT ('123XYZ',6.) returns an error, even though within the specified
width there is a valid numeric value prior to the invalid characters.
Off the top of my head, I can't think of any good reason why INPUT
('1JAN5ABCD',DATE9.) should not return an error. The underlying
situation appears to be the same. (Trailing blanks should be OK, of
course.)

Mike Rhoads
Westat
RhoadsM1(a)Westat.com

-----Original Message-----
From: owner-sas-l(a)listserv.uga.edu [mailto:owner-sas-l(a)listserv.uga.edu]
On Behalf Of Scott Barry
Sent: Tuesday, January 16, 2007 5:20 PM
To: SAS-L ListServ Group
Subject: Re: Safe way to test if a date is valid ?


....

Also, I would consider the SAS DATE INFORMAT processing of
alpha-characters in the year to be an
serious defect without question. Hopefully SAS Institute can understand
why, presuming someone
reported the behavior?

For many years I've used the DATA step technique with INPUT function and
checking _ERROR_ to
validate a user-specified date string as being correct. To see Dan's
post is disquieting.

Sincerely,

Scott Barry
SBBWorks, Inc.
From: "data _null_;" on 17 Jan 2007 09:42
I don't really see a problem. To me and my limited experiments it
looks like the INFORMAT "looks" for a pattern D[D]mmmY[Y[Y[Y]]] and
ignores data that may be following. Seems reasonably acceptable to
me.

On 1/17/07, Scott Barry <sbarry(a)sbbworks.com> wrote:
> This is ridiculous - I opened a SAS support track to report the year interpretation problem.
>
> -----Original Message-----
> From: Scott Barry [mailto:sbarry(a)sbbworks.com]
> Sent: Tuesday, January 16, 2007 5:20 PM
> To: SAS-L ListServ Group (sas-l(a)listserv.uga.edu)
> Subject: Re: Safe way to test if a date is valid ?
>
>
>
> FYI - A lowercase month was interpreted correctly with SAS on Windows and z/OS platforms.
>
> Also, I would consider the SAS DATE INFORMAT processing of alpha-characters in the year to be an
> serious defect without question. Hopefully SAS Institute can understand why, presuming someone
> reported the behavior?
>
> For many years I've used the DATA step technique with INPUT function and checking _ERROR_ to
> validate a user-specified date string as being correct. To see Dan's post is disquieting.
>
> Sincerely,
>
> Scott Barry
> SBBWorks, Inc.
>
> <snip>
>
From: Scott Barry on 17 Jan 2007 09:13
This is ridiculous - I opened a SAS support track to report the year interpretation problem.

-----Original Message-----
From: Scott Barry [mailto:sbarry(a)sbbworks.com]
Sent: Tuesday, January 16, 2007 5:20 PM
To: SAS-L ListServ Group (sas-l(a)listserv.uga.edu)
Subject: Re: Safe way to test if a date is valid ?



FYI - A lowercase month was interpreted correctly with SAS on Windows and z/OS platforms.

Also, I would consider the SAS DATE INFORMAT processing of alpha-characters in the year to be an
serious defect without question. Hopefully SAS Institute can understand why, presuming someone
reported the behavior?

For many years I've used the DATA step technique with INPUT function and checking _ERROR_ to
validate a user-specified date string as being correct. To see Dan's post is disquieting.

Sincerely,

Scott Barry
SBBWorks, Inc.

<snip>
From: Venky Chakravarthy on 17 Jan 2007 10:09
Hi Mike,

That was my feeling too. However, going back a few years on this list, I
seem to recall another thread that was similar and I think I can apply that
explanation here to make some sense of it.

Note that the documentation is clear on stating that leading zeroes do not
affect numeric values. So when you write

input('1JAN5ABCD',DATE9.)

it is similar to a and c below when viewed in the context of the YEARCUTOFF
option:

data _null_ ;
a = input ('01JAN0005ABCD',DATE9.) ;
b = input ('1JAN5ABCD',DATE9.) ;
c = input ('0001JAN0005ABCD',DATE11.) ;
put a=date9. b=date9. c=date9. ;
run ;

Which yields the following in the log:

a=01JAN2005 b=01JAN2005 c=01JAN2005

I agree that this behavior has a strange feel to it but I think it is also
instrumental in rendering some of the flexibility to SAS in reading in date
values. I guess there is more good than bad coming out of this behavior so
it may be more of a feature than a bug.

Here is my response to a similar question from a previous thread in 2001
and the link to a SAS Note that details this behavior.

http://listserv.uga.edu/cgi-bin/wa?A2=ind0112B&L=sas-l&P=R6447

http://support.sas.com/techsup/unotes/V6/0/0573.html

Regards,

Venky


On Wed, 17 Jan 2007 08:33:10 -0500, Mike Rhoads <RHOADSM1(a)WESTAT.COM> wrote:

>Scott,
>
>This seems odd to me as well.
>
>INPUT ('123XYZ',6.) returns an error, even though within the specified
>width there is a valid numeric value prior to the invalid characters.
>Off the top of my head, I can't think of any good reason why INPUT
>('1JAN5ABCD',DATE9.) should not return an error. The underlying
>situation appears to be the same. (Trailing blanks should be OK, of
>course.)
>
>Mike Rhoads
>Westat
>RhoadsM1(a)Westat.com
>
>-----Original Message-----
>From: owner-sas-l(a)listserv.uga.edu [mailto:owner-sas-l(a)listserv.uga.edu]
>On Behalf Of Scott Barry
>Sent: Tuesday, January 16, 2007 5:20 PM
>To: SAS-L ListServ Group
>Subject: Re: Safe way to test if a date is valid ?
>
>
>...
>
>Also, I would consider the SAS DATE INFORMAT processing of
>alpha-characters in the year to be an
>serious defect without question. Hopefully SAS Institute can understand
>why, presuming someone
>reported the behavior?
>
>For many years I've used the DATA step technique with INPUT function and
>checking _ERROR_ to
>validate a user-specified date string as being correct. To see Dan's
>post is disquieting.
>
>Sincerely,
>
>Scott Barry
>SBBWorks, Inc.
First  |  Prev  |  Next  |  Last
Pages: 1 2 3 4 5
Prev: Which to use, SAS or SUDAAN?
Next: PROC OPTMODEL: does it solve Mixed Integer Programming problems?