Info

This question is closed. Reopen it to edit or answer.

datestr: What is the expected behaviour?

1 view (last 30 days)
Martin Vatshelle
Martin Vatshelle on 6 Aug 2015
Closed: MATLAB Answer Bot on 20 Aug 2021
The normal behaviour is:
datestr(datenum('1408260615','yymmddHHMM',1990)) -> 26-Aug-2014 06:15:00
On faulty input the conversion don't work:
datestr(datenum('140826061S','yymmddHHMM',1990)) -> 26-Aug-2014 06:01:00
- here 1S is interpreted as 1 which is a reasonable thing to do
datestr(datenum('1408330615','yymmddHHMM',1990)) -> 02-Sep-2014 06:15:00
-here I would expect an error (but at least it is a logical date to return)
datestr(datenum('P1408260615','yymmddHHMM',1990)) -> 01-Jan-2015
-how did this date occur?
datestr(datenum('1408260S15','yymmddHHMM',1990)) -> Error using datenum (line 178)
DATENUM failed.
-This is expected behavour.
I made the following code to check:
function [valid] = validDate(date)
valid = false;
try
if isequal(date, datestr(datenum(date,'yymmddHHMM',1990),'yymmddHHMM'))
valid = true;
end
catch
end
end
Is there a better way of checking for a valid date?
  1 Comment
dpb
dpb on 6 Aug 2015
All of your examples above (save one) that have peculiarities or error are those in which the date string includes a character other than numeric...checking and not passing a malformed string such as that would be my first step.
On the datenum('1408330615',... case, that is documented behavior that datenum will roll over any field to the next higher granularity level accounting for days in months, leap years, etc., etc., ... This is very useful behavior in generating time series, for example, where one can pass a vector of differential times and return the date numbers associated with same. This case should NOT be considered nor expected to be an error.
I've not considered your proposed function in length, only that I'd just throw out most of your error cases a priori simply owing to the misplaced or existing characters in the input string before further consideration.
In practice, perhaps the case with the leading 'P' might be a substring selection coding error, in that case the length is wrong as well for the conversion field. On the '1S' being "reasonable" perhaps, but it's still wrongly formatted so I'd generally want it to be rejected as well; again the existence of the character in a numeric field is the giveaway. The embedded 'S' is easy...
It gets more difficult in the case of '0833' and the like where they are numeric but one doesn't know whether that's intended as, as mentioned above, a offset time of some number of days since a known date is intended or whether it is simply an error that the typist hit the '3' key when meant '2'. Application context might help if the former is a possibility but if one is reading a database of supposedly valid dates it's clearly an error whether datenum can handle it or not.
Dates are, by their very nature of encoding, a conundrum to handle.

Answers (0)

Community Treasure Hunt

Find the treasures in MATLAB Central and discover how the community can help you!

Start Hunting!

Translated by