Thanks for providing and for applying the changes.

The new tests are passing in our CI.

Closing as fixed.

This is still not corrected in octave 7.2.0. Does anyone want to include this fix?

ok, thanks for the reminder Georg.

it helps maintainers consider code changes when they've been made into a patch on the Octave codebase. (See https://wiki.octave.org/Mercurial if you want to see how to produce one.)

I had difficulty creating a patch by just adding your file to the current codebase, it appears you based it on a fairly old version of the function with a different copyright header, and your system used a different line ending (linux usually user LF, Windows uses CR/LF, yours just used CR.). Octave should be able to be set to save with LF endings.  for the former, always try to make changes using the latest development sources (see link above).

Anyway, adjusting for those was fairly simple. i also added a few of the examples in these comments as tests and checked them against matlab.  The patched file passes all tests and seems to fix this bug.

attached is the patch that makes these changes and adds a comment to NEWS about the bugfix as well as the updated addtodate.m file with those changes

i used your name as patch author, but do you want an email address added as well? that can be added if/when this gets pushed to the codebase.

(file #52203, file #52204)

Would be happy if someone could include this fix into next release.

For the records: Bug is still present in octave 6.1.0 (Mac OSX).

I think changing changing lines 65 and 66 in addtodate.m to the following loops will be safer. Is this OK for edge cases?

do
    ii = (dtmp(:,2) < 1); # these entries are underflowing
    dtmp(ii,2) += 12;  # go from Month 0 to Month 12, etc
    dtmp(ii,1) -= 1;   # and decrement year
until (~any(ii));

do
    ii = (dtmp(:,2) > 12); # these entries are overflowing
    dtmp(ii,2) -= 12;  # go from Month 13 to Month 1, etc
    dtmp(ii,1) += 1;   # and increment year
until (~any(ii));

Thank you for the bug report. It looks like the behavior is chaotic about whether it returns the same month or the previous month:

octave:12> datestr (addtodate (datenum('31-Jan-2020'), -1,'month'))
ans = 31-Dec-2019
octave:13> datestr (addtodate (datenum('31-Mar-2020'), -1,'month'))
ans = 02-Mar-2020
octave:14> datestr (addtodate (datenum('31-May-2020'), -1,'month'))
ans = 01-May-2020
octave:15> datestr (addtodate (datenum('31-Jul-2020'), -1,'month'))
ans = 01-Jul-2020
octave:16> datestr (addtodate (datenum('31-Aug-2020'), -1,'month'))
ans = 31-Jul-2020
octave:17> datestr (addtodate (datenum('31-Oct-2020'), -1,'month'))
ans = 01-Oct-2020
octave:18> datestr (addtodate (datenum('31-Dec-2020'), -1,'month'))
ans = 01-Dec-2020

For the other months, it at least seems to be consistently decrementing the month:

octave:20> datestr(addtodate (datenum('29-Feb-2020'), -1,'month'))
ans = 29-Jan-2020
octave:21> datestr(addtodate (datenum('30-Apr-2020'), -1,'month'))
ans = 30-Mar-2020
octave:22> datestr(addtodate (datenum('30-Jun-2020'), -1,'month'))
ans = 30-May-2020
octave:23> datestr(addtodate (datenum('30-Sep-2020'), -1,'month'))
ans = 30-Aug-2020
octave:24> datestr(addtodate (datenum('30-Nov-2020'), -1,'month'))
ans = 30-Oct-2020

The bug seems to be in these two lines within addtodate.m, which fail sometimes when the second argument q is negative:

      dtmp(:,1) += floor ((dtmp(:,2)-1)/12);
      dtmp(:,2) = mod (dtmp(:,2)-1, 12) + 1;