DATENUM(x, 30)
Jan Simon
This fails in Matlab 2009a:
n = datenum(datestr(now, 30), 30)
with the message:
Failed to lookup month of year.
The other formats are working, e.g.
n = datenum(datestr(now, 29), 29)
I cannot find this in the bugreports:
http://www.mathworks.com/support/bugreports
Am I searching correctly??
Is this still buggy in 2010a?
Kind regards, Jan
Steven Lord
"Jan Simon" <matlab.T...@nMINUSsimon.de> wrote in message
news:i0e1r8$c5m$1...@fred.mathworks.com...
> Dear readers,
>
> This fails in Matlab 2009a:
> n = datenum(datestr(now, 30), 30)
> with the message:
> Failed to lookup month of year.
Use this instead:
datenum(datestr(now, 30), 'yyyymmddTHHMMSS')
> The other formats are working, e.g. n = datenum(datestr(now, 29), 29)
I'm pretty sure that the reason it works is not the reason you think it
does.
Let's look at the documentation for DATENUM.
http://www.mathworks.com/access/helpdesk/help/techdoc/ref/datenum.html
When you use the datenum(..., 30) or datenum(..., 29) cases you _think_
you're using the datenum(S, F) syntax, right? Well, 29 and 30 are not
strings so I'm pretty sure you're using the datenum(S, P) syntax [which is
related to the datenum(S) syntax] instead. I also believe that the comment
that says that only strings in specified formats may be used is out-of-date
and that format 29 may be acceptable for the datenum(S) syntax as well.
[I'll check this with the developers.]
Now how does NOW look in date format 29?
>> datestr(now, 29)
2010-06-29
Since the year is expressed using 4-digits, when you try to convert that
back into a date number there's no need for the pivot year. That's why your
second example worked.
--
Steve Lord
sl...@mathworks.com
comp.soft-sys.matlab (CSSM) FAQ: http://matlabwiki.mathworks.com/MATLAB_FAQ
To contact Technical Support use the Contact Us link on
http://www.mathworks.com
Matt Fig
cnt = 1;
for ii = 1:30
try
datenum(datestr(now,ii),ii);
catch
er(cnt) = ii;
cnt = cnt+1;
end
end
er =
3 4 5 7 8 9 10 11 17 18 27 30
17,18 and 27 I expect from the doc. But this would seem to indicate the rest should work:
"Certain formats may not contain enough information to compute a date number. In these cases, hours, minutes, seconds, and milliseconds default to 0, the month defaults to January, the day to 1, and the year to the current year."
TideMan
wrote:
But it fails in my old version 2006a as well, so there's nothing new
here.
Not that I would ever use format no 30 - weird bloody format it has.
Jan Simon
> > This fails in Matlab 2009a:
> > n = datenum(datestr(now, 30), 30)
> Use this instead:
> datenum(datestr(now, 30), 'yyyymmddTHHMMSS')
Thanks, you solved my confusion.
Digging in the -let me tell it- voluminous code of DATENUM (which calls DATEVEC, which calls DATEUM again) for my problem confirmed, that I've misunderstood the documentation.
DATENUM cannot be called with a numerical specifier for the input format, although it can sometimes produce the correct answer.
Thanks Matt and TideMan. The behaviour was not new, but it did not equal my expectations and I assume, that even an old bug could be a bug.
Kind regards, Jan
Matt Fig
N = datenum(S, F) converts one or more date strings S to serial date numbers N using
format string F to interpret each date string. .... See the datestr reference page to find valid string values for F. These values are listed in Table 1 in the column labeled "Dateform String."
It is the reference to the column label which I missed before. Otherwise it does seem intuitive that both functions should have access to the Dateform Number convention as well as the Dateform String.
Jan Simon
> Here is the relevant line from the documentation for DATENUM:
>
> N = datenum(S, F) converts one or more date strings S to serial date numbers N using
> format *string* F ...
>
> Otherwise it does seem intuitive that both functions should have access to the Dateform Number convention as well as the Dateform String.
The hypothetical intuitive DATENUM(x, 31) suffers from the same incomplete definition of years using 2 digits as the old Y2K problem. The artifical need of a pivot year is caused by some programmers, who wanted or needed to save 2 bytes in the early 70th or the last century.
But before I ask these programmers to come forward and excuse themselves for the current inconveniences of DATENUM, I admit, that my DateStr2Num published in the FEX cannot handle dates with more than 4 digits. In 9999 the FEX users will condemn me for this limitation, while I'm sure, that TMW will expand DATENUM for this case - and make it slower again. I'd be the last who asks TMW to reduce backward compatibility!
DATESTR, DATENUM, DATEVEC are so powerful and intelligent, that they are surprisingly slow. The much simpler and faster MEX functions DATENUMMX and DATEVECMX are shipped with the toolboxes and it would be very nice, if TMW would document them - and use them consequently. E.g. the command NOW would be much faster, if it calls DATENUMMX instead of DATENUM (checked until 2009a only).
In consequence, I'm using DATESTR and DATENUM to parse user inputs only to care for invalid formats, while all operation on already validated dates are performed by simpler and 25 to 100 times faster M- and Mex-functions (see DateConvert and DateStr2Num on the FEX).
Kind regards, Jan
us
that's why we've overloaded these functions for years...
us
Jan Simon
> > But before I ask these programmers to come forward and excuse themselves for the current inconveniences of DATENUM,
...
> > DATESTR, DATENUM, DATEVEC are so powerful and intelligent, that they are surprisingly slow.
> that's why we've overloaded these functions for years...
I'm not sure if your reply concerns the 1st or 2nd statement. ;-)
Could I dare to ask you for sharing your overloaded functions - either in the FEX or even better inside the Matlab toolboxes?
It was at least worth to ask. Wasting computing time is equivalent to wasting petroleum, e.g. by pouring it into the sea.
Kind regards, Jan