apjanke
commented
3 weeks ago Interesting. This looks like it's somewhat about how Leap Day is handled when adding a calendar-year increment.
>> fecha1 = datetime([2020 2 29 21 0 15]);
>> fecha2 = datetime([2025 1 1 0 0 0]);
>> incy = calyears(2);
>> vec1 = fecha1:incy:fecha2
vec1 =
29-Feb-2020 21:00:15 01-Mar-2022 21:00:15 01-Mar-2024 21:00:15 01-Mar-2026 21:00:15That last vec1(4) of 2026-03-01, higher than fecha2's 2025-01-1, is just wrong. I bet there's an off-by-one bug in the end condition there.
As for the other differences: 2020 was a leap year, so Feb 29 2020 existed. But there's no Feb 29 in 2022. My code is normalizing it up to March 1, like what happens when you pass "denormalized" out-of-range values to a datetime() constructor call.
>> datetime(2020, 2, 29)
ans =
datetime
29-Feb-2020But it looks like when adding a calyear (or calmonth), Matlab normalizes the nonexistent Feb 29 leap day down to Feb 28 instead, on non-leap years.
I wonder if there's documentation or reference for this behavior. The Matlab doco page for `calyears says "Calendar years account for leap days when used in calendar calculations", but it doesn't say how it accounts for them. (Same for the calmonths and calendarDuration pages, to my eyes.)
Matlab datetimes and datenums are ISO calendar dates, I believe. I wonder if the ISO date/time standards specify how calendar interval arithmetic works, and how to handle leap years in them.
The other aspect of this seems to be how calendar intervals work when used as the middle operand in a "lo:d:hi" two-colon expression. It is surprising to me that vec1(3) in your Matlab example is Feb 29. I would have thought it would be Feb 28, even though 2024 is a leap year. That's because I thought that the "lo:d:hi" two-colon operator generally worked like repeatedly adding d to a working value initialized with lo, copying successive results into elements of the output, until the next value would be larger than hi. Like this:
% y = lo:d:hi - how I thought it worked (approximately)
y = repmat(lo, [0 0]);
tmp = lo;
while tmp <= hi
y(end+1) = tmp;
tmp = tmp + d;
endIn this case, once tmp is normalized to a Feb 28 (or March 1) for a non-leap year, I'd expect it to never turn back in to Feb 29, because adding a d of 1 calyear to a Feb 28 will always produce a Feb 28.
But instead, it looks like it's doing y(s) = lo + (d * s); ("s" for "step" here). I looked at Matlab's colon doco, and it seems that's maybe the right way.
x = j:i:k creates a regularly-spaced vector x using i as the increment between elements. The vector elements are roughly equal to [j,j+i,j+2i,...,j+mi] where m = fix((k-j)/i).
That sounds more like y(i) = lo + (s * d) than repeatedly doing tmp = tmp + d. (It doesn't result in a "regularly-spaced" vector in the case of datetime and a calyear/calmonth i, but close enough.)
(Octave's documentation for colon isn't as detailed and doesn't seem to provide any guidance here.)
Fixing the upper bound bug is straightforward. I'll go ahead and do that.
I want to do a bit more reading to better understand the definition/specification here around the leap day normalization and "stride". (If you have any relevant links or books, I'd be happy to hear them.) But it sounds like Tablicious here needs two changes for Matlab compatibility: have datetime + calyears normalize down instead of up for nonexistent Feb 29s, and change the colon operator to do y(s) = s * d instead of repeatedly adding d to a working value.
jgpallero
See this example:
When I create a sequential vector of dates using the colon operator all works apparently well as the vector stops in an element lower than the last date.
But when I use years the result is not correct:
in Matlab the result is
the last element is always <= the greater limit. The bug is also present using calmonths()
I don't know if this bug is related with #134
Andrew's notes
Concise repro code:
TODO
hi:inc:locase for negativeincvalues. Currently just returns an empty array.lo:inc:hiproduces a descending sequence of values, and vice versa forhi:inc:logiving ascending values.