datetime error/inconsistency

>> datetime(1963,0,213)
ans = 
   01-Jul-1963
>> datestr(datenum(1963,0,213))
ans =
01-Aug-1963
>> sum(eomday(1963,1:7))
ans =
   212
>>

First is wrong; old datenum gets it right.

Whassup w/ that???

[Stephen23]

"old datenum gets it right."

I always found datenum's inconsistent treatment of zero and negative month values as bizarre and sometimes downright counterproductive. Good to see that this has been fixed with datetime.

[James Tursa]

@Stephen: "bizarre" ... agreed. The special treatment of zero or negative month values was never intuitive to me and I could never come up with a reason why I would want that behavior. I much prefer the datetime treatment.

Answer 1

[Walter Roberson]

Month 0 is the last month of the previous year, not the first month of that year.

https://www.mathworks.com/help/matlab/ref/datetime.html#input_argument_d0e187877

"If an element of the Y, M, or D inputs falls outside the conventional range, then datetime adjusts both that element and the same element of the previous input."

[dpb]

But the examples don't help with this one; it adjusts 70 min to 1 hr 10 min the next hour, or -15 min goes back one hour and leaves 45 sec.

Y + 0M + NDays isn't Y-1M + N Days; it's the N Days of the year, just as datenum has done "since forever". It's introducing yet another inconsistent incompatibility that's unnecessary that's the most frustrating.

[Walter Roberson]

[2014 1 1] is not one month and one day past the beginning of 2014: it is 0 months and 0 days past the beginning of 2014. Therefore [2014 0 1] is 1 month and 0 days before the beginning of 2014, which is [2013 12 1]

[Stephen23]

The inconsistency is fundamentally a human one: we start counting all time units from zero, but start counting from one for dates, months and years ( year zero is a myth, and has never been used in the Anno Domini system):

>> datevec(1)
ans =
   0   1   1   0   0   0

IMO it is quite appropriate to treat month 0 as being the previous month from month 1, and would expect this to extend in both directions without any special cases.... even better, we could simply change our language conventions and use a consistent start value for all units. Anyone up for a change?

Answer 2

[James Tursa]

This inconsistency has been noted before in previous posts. E.g., with datenum you get the same answer with month=0 and month=1:

>> datenum(1963,0,1)
ans =
      716972
>> datenum(1963,1,1)
ans =
      716972

I would have to do a search to try and find those relevant old posts to see what the conclusions were, if any. From the datenum doc:

"If an element falls outside the conventional range, datenum adjusts both that date vector element and the previous element. For example, if the minutes element is 70, datenum adjusts the hours element by 1 and sets the minutes element to 10. If the minutes element is -15, then datevec decreases the hours element by 1 and sets the minutes element to 45. Month values are an exception. datenum sets month values less than 1 to 1."

So, for what the user probably intends, the datetime interpretation of month=0 is probably what would be considered "correct". But that could of course depend on the actual application. E.g., to get a match:

>> datenum(1963,1,213-31)   <-- adjusted by number of days in December
ans =
      717153
>> datenum(datetime(1963,0,213))
ans =
      717153

[dpb]

I just discovered it.

I'm adamantly opposed to the new interpretation -- see note to Walter on why.