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.
