Date: Wed, 1 May 2002 10:31:06 -0700
Reply-To: Cassell.David@EPAMAIL.EPA.GOV
Sender: "SAS(r) Discussion" <SAS-L@LISTSERV.UGA.EDU>
From: "David L. Cassell" <Cassell.David@EPAMAIL.EPA.GOV>
Subject: Re: more on ANYDT* informatting
Content-type: text/plain; charset=us-ascii
I recently was discussing on this list a problem I hit when trying
out the ANYDT* informats and the DATESTYLE= option while I was at
the V9 hands-on workshop at SUGI. I have since been talking with
a 'little birdie', and I want the list to see what he has to say on
the subject. This is instructive. His text [in two messages]
follows my .sig .
David
--
David Cassell, CSC
Cassell.David@epa.gov
Senior computing specialist
mathematical statistician
************************************ FIRST MESSAGE
*************************************
I'm responding with more detail regarding the ANYDT* informats, most
specifically the
ANYDTDTE informat to read various representations of SAS date values.
David C. had commented in his SAS-L post that he encountered problems
when trying
out the ANYDTDTE informat at SUGI. I have checked out the current
version that's going
out with 9.0 and didn't see the same results. I'm showing my log here
with some additional
explanations. Let's be sure that everyone is clear on the proper
results, and then perhaps
either David C. or Dave R. can post to SAS-L for clarification, to
ensure that readers don't
get the wrong impression regarding the informat.
If the DATESTYLE option is set to MDY, YMD, etc., the option value is
used only when there
is an ambiguity that cannot be overcome. To use David C.'s 05/04/03
example, we don't know
which is the month, day, and year. In this case, the DATESTYLE option is
crucial in order
to compute the proper SAS date value. The following portion of the SAS
log shows this is
being done properly:
1 options datestyle=mdy;
2 data _null_; x=input('05/04/03',anydtdte8.); put x=date9.;
run;
x=04MAY2003
3 options datestyle=dmy;
4 data _null_; x=input('05/04/03',anydtdte8.); put x=date9.;
run;
x=05APR2003
5 options datestyle=ymd;
6 data _null_; x=input('05/04/03',anydtdte8.); put x=date9.;
run;
x=03APR2005
Now we try a value that is unambiguous. 31/12/2002 can only be 31DEC2002
because we use a 4-digit
year, and 31 can't be a month. So regardless of the DATESTYLE setting,
we still know that the proper
pattern for this input is DMY:
7
8 options datestyle=mdy;
9 data _null_; x=input('31/12/2002',anydtdte10.); put x=date9.;
run;
x=31DEC2002
10 options datestyle=ymd;
11 data _null_; x=input('31/12/2002',anydtdte10.); put x=date9.;
run;
x=31DEC2002
Now we have a case where the 4-digit year is used, removing year
ambiguity, both the month and day
are ambiguous, so again we must rely on DATESTYLE. And if we use YMD for
DATESTYLE, the value
of 05/12/2002 will be treated as missing because it would be invalid.
Something I still need to work on is
to make this produce an error message instead of simply treating it as
missing.
12
13 options datestyle=mdy;
14 data _null_; x=input('05/12/2002',anydtdte10.); put x=date9.;
run;
x=12MAY2002
15 options datestyle=dmy;
16 data _null_; x=input('05/12/2002',anydtdte10.); put x=date9.;
run;
x=05DEC2002
17 options datestyle=ymd;
18 data _null_; x=input('05/12/2002',anydtdte10.); put x=date9.;
run;
x=.
Here is a case where we use 2-digit years, but yet we still don't have
ambiguity. In the case of 55/12/31,
we know that 55 can only be a year, and therefore 31 can only be a day,
leaving 12 as the month. So now
regardless of the DATESTYLE setting, we use the YMD pattern:
19
20 options datestyle=ymd;
21 data _null_; x=input('55/12/31',anydtdte10.); put x=date9.;
run;
x=31DEC1955
22 options datestyle=mdy;
23 data _null_; x=input('55/12/31',anydtdte10.); put x=date9.;
run;
x=31DEC1955
24 options datestyle=dmy;
25 data _null_; x=input('55/12/31',anydtdte10.); put x=date9.;
run;
x=31DEC1955
I had various discussions with SUGI attendees regarding whether the
DATESTYLE option should be used only
to resolve ambiguities (as it does above), or if should indicate the
pattern to always use when a set of three
numeric tokens were encountered. I felt that since the purpose of the
informat is to figure out all it can, the
DATESTYLE option should only be used to resolve ambiguities. I welcome
further discussion on this issue.
Just so all know, the ANYDTDTE informat can be used with datetime input,
and the date part will be extracted.
(If used with time input, it always returns 01JAN1960). ANYDTTME can be
used with datetime input, and the
time part will be extracted. (If used with date input, it always returns
00:00:00). ANYDTDTM can be used with
date input (considered that date at midnight) or with time input
(01JAN1960, at that time of day), and of course
datetime input.
Let me know if further clarification is needed.
************************************ SECOND MESSAGE
*************************************
[my reply]
Thanks for tracking this. Your case number 3 looks most like
the problem I hit at SUGI in the V9 workshop:
> 5 options datestyle=ymd;
> 6 data _null_; x=input('05/04/03',anydtdte8.); put x=date9.;
run;
>
> x=03APR2005
However, I gave the system a slightly different choice. Using
DATESTYLE=ymd I made the date look more like 05/04/01 , which gave
the system a choice between a date years in the future and a 'current'
date which would not fit the 'YMD' hint. [Okay, I admit it, this was
over two weeks ago and I am sure I do not have the details exactly
correct.] To my surprise, the system chose to go with the 'current'
date and reported that the input represented a date in 2001. Can you
check
that the current V9 build handles this case too?
[the birdie's response]
There might be confusion w.r.t. the YEARCUTOFF= option.
The ANYDT* informats call the necessary informat once they figure out
the
right one to call. In our examples, the informat would be MMDDYY,
YYMMDD,
or DDMMYY, depending on what the algorithm determines. These informats
then use the YEARCUTOFF option to resolve 2-digit years. The default
YEARCUTOFF in V8 and in V9 is 1920, so '01' would be considered 2001.
I verified this with a subsequent test.
