[POLL] Dealing with +1m/y repeaters when jumping to impossible date (should 05-31 +1m be 07-01 or 06-30?) (was: Leap-year bug with todo-cycle)

[Ihor Radchenko]

Anton Haglund <aoh@lysator.liu.se> writes:

> I think I have discovered a possible leap-year bug in todo-cycle.
>
> I have a TODO-entry which looks like this:
>
> SCHEDULED: <2024-02-29 Thu ++1y>
>
> When I cycle the TODO-entry with c-c c-t it becomes
>
> SCHEDULED: <2025-03-01 Sat ++1y>

This is expected. When we try to add 1 year to 2024-02-29, it is
2025-02-29. However, because 02-29 does not exist in 2025, we glibc
takes the closest existing date and adds the difference in days:
2025-02-28 + 1d = 2025-03-01.

We apply the same logic to +1m repeaters:

SCHEDULED: <2024-05-31 Fri ++1m>
will become
SCHEDULED: <2024-07-01 Mon ++1m>
since 2024-06-31 does not exist.

> In my opinion it should become "2025-02-28 Fri" instead.

Keeping "end of a month" being end of a month is indeed an alternative
approach in such a situation. Both are possible; we just use the one
that is easier to implement from technical perspective.

Generally, I did see several requests to change the strategy when
calculating next month/year. However, that would be a breaking change.
I'd only go for it if people are strongly in favor of the change.
So, changing this to a poll.

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at <https://orgmode.org/>.
Support Org development at <https://liberapay.com/org-mode>,
or support my work at <https://liberapay.com/yantar92>