|
Dear M, Welcome to SAS, and to SAS-L. You will find some fine people
posting here, happy to help you with your problems.
I think the informat Peter suggested is a fine solution. One of its biggest
advantages is that it produces a SAS date value directly. SAS date values
are very nice in several ways. They are actually just offsets in days from
the reference date (01/01/1980), but SAS has many formats and functions to
work with them.
If you choose to keep the TEXTDATE approach, I suggest you not add TEXTDATE
to the output dataset. Instead, define a second variable, DATE:
> DATA DATE1(KEEP=DATE);
> INPUT @1 TEXTDATE $10. ;
>
> IF TEXTDATE = '01/01/0001' THEN DATE=.;
ELSE DATE=INPUT(TEXTDATE,MMDDYY10.);
FORMAT DATE MMDDYY10.;
> CARDS;
> 01/01/0001
> ;
>
> PROC PRINT DATA=DATE1;
>
>
> ----------
> From: M. Heinemann[SMTP:Melinda_Heinemann@NOTES.TOYOTA.COM]
> Reply To: Melinda_Heinemann@NOTES.TOYOTA.COM
> Sent: Tuesday, November 02, 1999 1:52 PM
> To: SAS-L@LISTSERV.UGA.EDU
> Subject: Re: SAS Date problem
>
> I am new to SAS after 30 years as an IBM Mainframe COBOL applications
> programmer. So, I thank you all for your valuable input.
>
> I believe I will take the simplest approach to the date problem. This
> code
> seems to work the way I want and changes TEXTDATE to "missing". There
> is the
> problem of redefining TEXTDATE to MMDDYY10. somehow.
>
> DATA DATE1;
> INPUT @1 TEXTDATE $10. ;
>
> IF TEXTDATE = '01/01/0001' THEN TEXTDATE=.;
> CARDS;
> 01/01/0001
> ;
>
> PROC PRINT DATA=DATE1;
>
>
>
>
> Peter Crawford <peter.crawford@DB.COM> on 11/02/99 12:05:58 PM
>
> Please respond to peter.crawford@DB.COM
>
> To: SAS-L@LISTSERV.UGA.EDU
> cc: (bcc: Melinda Heinemann/IS/TMS/Toyota)
>
> Subject: Re: SAS Date problem
>
>
>
> well that is emphatic enough ... no
> I was considering a user informat to handle such situations, almost
> transparently
> invalue dbdate
> '01/01/0001' = .D
> other = (! ddmmyy10. !)
> ;
> I don't like to throw away the info, so to meet Tim's preference, I'd
> follow the
> use of such an informat with data step statements like
> if thatdate = .D then
> do;
> thatmiss = 'null 1' ;
> thatdate = . ;
> end;
>
> Clearly, this isn't how the db2 interface would work, but.....
>
>
>
>
> Datum: 02.11.99 20:52
> An: Peter Crawford/Zentrale/DeuBaExt
> sas-l@uga.cc.uga.edu
>
>
>
> Betreff: RE: SAS Date problem
> Nachrichtentext:
>
>
>
> Peter, Perhaps a special missing value is appropriate here, perhaps
> standard
> missing values are appropriate here. I tend to avoid the special missing
> values. Casual coders test for equality to . more often than they test
> for
> less than or equal to .Z, so unless there is a specific reason for the
> missing value, I just use .. Even if there is a specific reason for the
> missing value, I just use .. If there are a variety of specific reasons
> for
> missing values, I still just use ., and I add a field for storing the
> reason.
> Tim
> > ----------
> > From: peter.crawford@db.com[SMTP:peter.crawford@db.com]
> > Sent: Tuesday, November 02, 1999 11:19 AM
> > To: TWB2@pge.com
> > Cc: SAS-L@listserv.uga.edu
> > Subject: Re: SAS Date problem
> >
> > would you consider using a special missing like .D for specifics like
> this
> > ?
> >
> <SNIP>
>
|
