The requested length is not used by format datetime. This:
data T1;
A=put(datetime(),datetime20. -l); L=length(A); putlog '20 ' L A ;
A=put(datetime(),datetime19. -l); L=length(A); putlog '19 ' L A ;
A=put(datetime(),datetime18. -l); L=length(A); putlog '18 ' L A ;
run;
yields:
20 18 20MAY2020:11:08:13 19 18 20MAY2020:11:08:13 18 16 20MAY20:11:08:13
The length created is always smaller than the length requested, and includes left padding.
This means that one must use a different format/informat for writing and then reading a date:
filename TMP temp;
data _null_;
file TMP ;
STR=catx(',','*',put(datetime(),datetime20. -l),'*');
put STR;
run;
data T2;
infile TMP dlm=',';
input A $ B datetime18. C $;
run;
The value is written with a length of 20 but must be read with an informat length of 18.
Writing with a length of 18 would mandate reading 16 characters.
And comments on this peculiar behaviour?
The online documentation examples of datetimew.d clearly show that behavior for datetime18. where the examples use default 16, 7, 12, 18, 18.1 19, 20.1 and 21.2
Personally I blame this on pre-Y2K mindsets for setting that behavior with 2 leading spaces instead of the 4 digit year.
Known bug. Been there as long as I can remember.
I am not too worried about the extra space, but the fact that it cannot generate 4 digit years when you ask for width of 18 is the one that causes confusion. 9 characters for DATE9. plus 8 characters for TIME8. plus a colon separator should fit into 18 characters.
Thanks @Tom . I've always forced a length of 20 to overcome a behaviour I knew was inconsistent with other formats. I just delved now into the details.
I'll ask tech support to explain the outputs, and to create a Usage Note if none exists. There's probably no way this will be corrected.
The online documentation examples of datetimew.d clearly show that behavior for datetime18. where the examples use default 16, 7, 12, 18, 18.1 19, 20.1 and 21.2
Personally I blame this on pre-Y2K mindsets for setting that behavior with 2 leading spaces instead of the 4 digit year.
Thanks guys.
> Personally I blame this on pre-Y2K mindsets for setting that behavior with 2 leading spaces instead of the 4 digit year
That could be an explanation.
From the documentation, it seems the concern may have been to leave space for the decimal dot and the first seconds digit. Why just the first digit? That's weird.
Afaik, no other format does this: systematically use less space than it is allowed (unless decimals are requested).
Storm in a tea cup then. Thanks again for taking the time to reply.
Don’t miss the livestream kicking off May 7. It’s free. It’s easy. And it’s the best seat in the house.
Join us virtually with our complimentary SAS Innovate Digital Pass. Watch live or on-demand in multiple languages, with translations available to help you get the most out of every session.
Learn how use the CAT functions in SAS to join values from multiple variables into a single value.
Find more tutorials on the SAS Users YouTube channel.
Ready to level-up your skills? Choose your own adventure.