Why could a function not account for this difference?
SAS has two data types, character and numeric. Dates are numeric. Datetimes are numeric. The value 100 is a valid date and a valid datetime and a valid time.
252 data _null_;
253 x=100;
254 put "X as a date: " x= date9.;
255 put "x as a datetime: " x= datetime18.;
256 put "x as a time: " x= time8.;
257 run;
X as a date: x=10APR1960
x as a datetime: x=01JAN60:00:01:40
x as a time: x=0:01:40
And the functions HOUR and MINUTE as well. Why not ask for Hour to work with Date values?
New functions make marginal sense such as DTYEAR but I doubt that having Year guess which value I meant based on a numeric value is just another version of the whole Y2K related garbage.
Why could a function not account for this difference?
Because there is no difference. All these values are numbers, and you can only use a range to make up a difference, and then the function would fail with small datetimes. This would introduce a bug like Excel has with the "leapyear" 1900, which makes it return wrong values for dates before 1900-03-01. No designer worth her/his money will do that.
But, as mentioned, a set of separate functions for datetimes would be feasible.
The function could look at the format associated with a value and use that to decide whether a value is a date, a datetime, or a time. I think that's how the DBTYPE and DBSASTYPE options in SAS/Access work. If you create a format with PROC FORMAT, you can specify DATATYPE=(DATE|TIME|DATETIME), so it should be possible to get that information back and use it.
What if your dates and datetimes were a few months before or after 01jan1960? Then the underlying values would overlap, and there would be no way for SAS to determine which usage was in hand.
For instance, would 300 represent 27OCT1960 or 5 minutes after midnight on Jan 1, 1960?
@mkeintz SAS/Access engines loading into a database identify numerical columns containing a SAS date or datetime value based on the format applied. I'm not asking for this but functions could in principle behave in a similar manner.
Functions operate on any expression that returns the type of value they support as arguments.
SAS has two types of values. Strings and floating point numbers.
SAS does not have DATE or DATETIME types. Both of those are represented by floating point numbers, just like all other numbers.
Are you saying you want a function that only allows you to pass a variable reference? Like VVALUE() or VLENGTH()? Or one that takes the name of a variable? Like VVALUEX() or VLENGTHX()? That would need to be a new function, not a modification to the existing function. And even if you did build a function like that how would it know what format to use to guess if the number in the variable is days or seconds? Is it the format that the variable has attached to it? What if you are reading a variable named DATE with second counts and using the DATEPART() function to convert it to day counts and a FORMAT statement to change the way it is displayed so it looks to humans like a date. How would the YEAR() function know if it is being called before or after the conversion was made?
At a minimum to allow the YEAR(), MONTH(), and DAY() functions to treat the number you pass it as a number of seconds instead of a number of days you would need to add an additional optional argument to the function where the programmer could tell that the values are seconds instead of days.
I would find it easier to just have new functions (as suggested about in this discussion). Prefix the names with DT. Like the prefix used in formats (DTDATE.) and intervals for INTNX() and INTCK() calculations ('DTYEAR', 'DTMONTH', 'DTDAY') that apply to datetime values.
@Patrick "SAS/Access engines loading into a database identify numerical columns containing a SAS date or datetime value based on the format applied. I'm not asking for this but functions could in principle behave in a similar manner."
Other than numeric vs character, I'm not aware of functions needing to know any other attribute of a variable. I have no doubt it's possible utilize a format as a hidden parameter of a function much as sas/access engines do for uploads. But I think it would introduce more issues than it might seem at first. In such a case, what should the function do if the format is best32., even though the user knows it's really a date, time, or datetime value? Generate an error message and a missing value perhaps? Make a default choice, and issue a note?
In other words, should SAS start to obligate the user to assign a format in order to prevent a function from failing, or doing the "wrong" thing? As far as I know, all sas numeric functions work on all sas numeric values (with domain exceptions like log of a negative). I wonder if the proposed function would need to break that feature when it's not the argument value, but rather the argument format that is not in the needed "domain".
