The function html_calendar in roundup/cgi/templating.py produces a help link that pops up a calendar for date selection.

This computes navigation links in the calendar:

date_prev_month = display + date.Interval("-1m")
date_next_month = display + date.Interval("+1m")

This fails on day 31 of a month due to limitations in our Date/Interval classes:

>>> from roundup import date
>>> d = date.Date ('2022-05-31')
>>> d + date.Interval ('+1m')
<Date 2022-07-01.00:00:00.000>
>>> d + date.Interval ('-1m')
<Date 2022-05-01.00:00:00.000>


Maybe that should be fixed by explicitly incrementing only the month of the given date.
On the other hand it only happens every two months :-)

Looks like the Interval class *tries* to do the right thing by preserving the semantics of a month (and year, see below) but fails when the next/prev month doesn't have this particular day (the 31st).

So it also fails in leap years for the same reason:
>>> from roundup import date
>>> d = date.Date ('2024-02-29')
>>> d + date.Interval ('+1y')
<Date 2025-03-01.00:00:00.000>
>>> d + date.Interval ('-1y')
<Date 2023-03-01.00:00:00.000>

Turns out this may be seen as a bug of the Date / Interval implementation and not of the calendar?
Should we try to fix it there?
Looks like there are no tests for these corner cases and we might rule that the behavior was undefined before?

duplicate of issue2550858 (Month intervals at the end of long months yield the wrong day)
from 2014.

> On the other hand it only happens every two months :-)

In February this happens more often, because it has only 28/29 days :)

I'll add two patches over there that have been sitting in my backlog since 2019.