Limits in hours in date vectors (datevec function)

Hello, I was wondering what are the true carryover limits to the date vectors. For instance, when I insert: A = [2000,1,1,30,0,0]; B = datestr(A); MATLAB understands that this is the 6th hour of the next day and correctly returns: '02-Jan-2000 06:00:00' Then if you return it as C = datevec(B); the date vector will have been fixed to the MATLAB format.

But if you insert something more extravagant, yet reasonable such as A = [2000,1,1,500,0,0]; (the 500th hour after the start of 01/01/2000), then datestr does not return a valid value. There appears to be a limit somewhere, even within the same month. Do you know the limits to this? One can easily make a workaround with a custom script, but MATLAB is supposed to do the carryover automatically.

[Kirby Fears]

I did some initial tests and found a limit for negative hours as well. However, the limit I find varies depending on the date I start with. Will post an answer if I find the actual cause.

I found that using datestr(datenum(A)) works in your example, so this appears to be a datestr(datevec) quirk.

Answer 1

[Kirby Fears]

This appears to be a bug in datestr() which you can report to Mathworks support.

In Matlab 2015a, datestr line 166 has an if statement including the following logic:

 &&...
    all(abs(sum(D,2)-2000)<500))

Where D is the datevector input (which is your variable A). The A you have specified fails this condition, which leads to these two lines executing:

% datestr() mistakenly thinks D is a datenum
(line 174): dtnumber = D; 
(line 183): dtnumber = dtnumber(:);

This is why you're getting a vector (6 long) of weird dates back. It's converting each of your datevec fields to a datestr as if they were datenums. This same bug would be encountered if you input a datevector for the year 2501 because of the conditional statement used to distinguish datenums from datevecs.

E.g. This should give you 6 wrong date strings instead of Jan 1, 2501

A = [2501 1 1 0 0 0]; disp(datestr(A));

An immediate workaround is to call datestr(datenum(A)).

A fix by Mathworks would involve revisiting the conditional in line 166 which is misidentifying your datevec as a datenum. If it were properly identified as a datevec, it would actually be put through the datenum function within datestr. Thus calling datestr(datenum(A)) yourself is a good workaround.

Hope this helps.

Answer 2

[Bouz]

Thank you Kirby Fears for your answer and your time! The workaround seems to be working well, it's generally better to use datenum instead of anything else (date vectors or strings).

This might not be interesting anymore, but to better understand what I was trying to do, I had the following problem: I want to randomly generate time events that have a random starting hour within one year. So it's much easier to count the hours within a year with a serial number from 0 to 8760-1 to create the random sample and then convert them to the date conventions used in MATLAB. One can do this with serial date numbers (datenum), much better than vectors or strings, as datenum is a unique number that increases by 1/24 per hour. But I wanted to keep the date vectors to provide a better overview of time handling so I did something like this (also see this topic ):

yearr = '2010';
ystr_start = ['01-Jan-' yearr ' 00:00:00'];
ystr_end = ['31-Dec-' yearr ' 23:00:00'];

a = datenum({ystr_start;ystr_end});
Out1 = datevec(a(1):1/24:a(2)); % All the hours for yearr in date vector format
Out2 = (0:1:365*24-1)'; % Cumulative hours for yearr

So then you can use Out2 as indexing to track down the vector date in Out1 for each randomly generated number. Initially I was thinking of using randomly generated numbers from the range of Out2 directly as the hour date vector (4th column), but as we saw this doesn't work. Alternatively, one can just generate the numbers with the datenum convention and then just datevec each randomly generated serial date number.