Anton Haglund <a...@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>
