Ihor Radchenko writes:
>> 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,
jman writes:
> I don't particularly have a skin in the game but I ask a question: what would
> be the impact of this breaking change for users with existing Orgmode
> documents?
Mostly that people familiar with the current behaviour might be
surprised.
I am personally slightly in favour of th
> 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.
I don't particularly have a skin in the game but I ask a
On Fri, Apr 05, 2024 at 06:34:29PM +, Ihor Radchenko wrote:
> > 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 implemen
Anton Haglund 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
Hi!
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>
In my opinion it should become "2025-02-28 Fri" instead. If yo
