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

[Ihor Radchenko]

Max Nikulin <manikulin@gmail.com> writes:

>>> On 13/05/2024 17:07, Ihor Radchenko wrote:
>>>>
>>>> <2025-01-31 Fri +1m>
>>>> <2025-02-28 Fri +1m>
>>>> <2025-03-28 Fri +1m>
>>>
>>> Instead of using timestamp obtained on previous step, use original
>>> timestamp and multiple of the interval.
>> 
>> This is not possible because of how `org-auto-repeat-maybe' is designed.
>
> Then the only way to get reasonable results is to store in :PROPERTIES: 
> either original date (and iteration count) or current date before 
> clamping (2025-02-31)

As Stefan pointed, even this is not a panacea - 2025-02-28 starting date
is simply ambiguous because it may either mean "last day of each month"
or "28th of each month".

Now, I am having second thoughts about how useful the customization I
proposed is - it looks like it is only changing one kind of unexpected
behavior with another.

I still want to work towards applying my patch for the purposes of
making agenda calculations for the repeater consistent with reality
(without the patch, `org-closest-date' and `org-timestamp-change' yield
different results because the former moves multiple repeater intervals
forward without considering date jumps), but I think that the
customization should be simply dropped.

>>> Have you considered using `min' with result of `date-days-in-month' here
>>> (or its sibling from timezone.el)?
>> 
>> Not sure if it is going to be simpler.
>
> My idea was to avoid the backward `while' loop in the code below this line.

That while loop is going to have 3 iterations at worst. So, I do not see
much benefit trading performance for complexity.

>> Although, forcing DST nil will not always help here
>
> It is fragile, I would not rely on ignoring offset when DST is 
> specified. Actually you pass mutually inconsistent values, so it is 
> either undefined behavior or close to it.

Yeah. I think that the easiest approach will be converting to UTC first,
making the shift, and then converting back to the original
timezone. That way, we will avoid issues with moving across DST
transition.

Also, special handling may be necessary for timestamps without time -
currently they are simply treated as 0:00 time, but it may backfire as
in my case with DST transition moving the date one day back.

-- 
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>