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

[Max Nikulin <manikulin@gmail.com>]

On 14/05/2024 19:56, Ihor Radchenko wrote:
> Max Nikulin 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)

> No idea. I am not aware about any existing built-in API that provides
> date increments.

The context was that day start time may give some surprise as well. I am 
unsure concerning namely increments. I just expected a set of more 
accurate functions for working with dates.

>>> +          (org-encode-time
[...]
>>> +            (+ (if (eq unit 'day) value 0)    (decoded-time-day time))
>>
>> 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.

>> (format-time-string
>>    "%F %T %Z %z"
>>    (encode-time '(0 30 12 15 1 2000 'ignored nil "Africa/Juba"))
>>    "Africa/Juba")
>> (error "Specified time is not representable")
> 
> Hmm. I am not sure if it is a real problem in practice.
> String values of time zone are only possible for hand-crafted time
> values.

This example avoids changing system time or starting Emacs with TZ 
environment. The following example does not include explicit timezone:

TZ=Africa/Juba emacs -Q --batch \
     --eval "(encode-time '(0 30 12 15 1 2000 'ignored nil nil))"

> The reason why I forced DST nil is hysteresis of glibc when dealing with
> DST transitions:

At first I was trying to figure out what time zone had 24:00<->23:00 
transition in 2012.

> (cl-loop for m in '(1 2 3 4 5 6 7 8 9 10 11 12)
>    collect (decode-time (encode-time `(0 0 0 4 ,m 2012 nil -1 10800))))
> 
> (0 0 23 3 1 2012 2 nil 7200)

This result depends on your timezone. It is consistent with e.g. 
Asia/Istanbul. It had +02:00 offset in January, but you requested 
+03:00. The result of conversion is -1 hour difference in requested 
timestamp and conversion result. It is unrelated to internal DST state 
and hysteresis caused by this state.

When DST is nil
2012-01-04 00:00:00 +03:00 === 2012-01:03 23:00:00 +02:00

Avoid passing timezone offset when you do not know it.

I agree that there are issues with handling tm_gmtoff and tm_isdst
https://data.iana.org/time-zones/theory.html#POSIX-extensions
Results may vary across libraries.

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