Max Nikulin <maniku...@gmail.com> writes: > On 13/05/2024 17:07, Ihor Radchenko wrote: >> >> However, there are still some issues remaining. >> When updating timestamps repeating monthly across months with 30, 31, >> and 28 days we get >> >> <2025-01-31 Fri +1m> >> <2025-02-28 Fri +1m> >> <2025-03-28 Fri +1m> >> ... >> <2026-01-28 Wed +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. When repeater is triggered, the original date in the timestamp is replaced with future date. So, we have no access to the original date in the timestamp. > I have the following in my notes. However I have not find suitable > functions in elisp: > > https://debbugs.gnu.org/54764#10 > Paul Eggert. Sat, 9 Apr 2022 00:52:57 -0700 >> Generally speaking, >> when Org mode is doing calendrical calculations it should use >> calendrical functions rather than encode-time+decode-time, which are >> best used for time calculations not calendar calculations. > > Do you have any idea what Paul was writing about? No idea. I am not aware about any existing built-in API that provides date increments. >> + (org-encode-time >> + (list >> + (+ (if (eq unit 'second) value 0) (decoded-time-second time)) >> + (+ (if (eq unit 'minute) value 0) (decoded-time-minute time)) >> + (+ (if (eq unit 'hour) value 0) (decoded-time-hour 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. >> +(defun org-time-inc (unit value time) > Is there a chance that support of intervals like 1h20m will be required > later? Not sure again. I simply used ts-inc function signature from Adam's ts.el as reference. >> + (+ (if (eq unit 'month) value 0) (decoded-time-month time)) >> + (+ (if (eq unit 'year) value 0) (decoded-time-year time)) >> + (decoded-time-weekday time) >> + (if (memq unit '(day month year)) >> + nil ; Avoid auto-adjustments of time when jumping across >> DST. > > Sorry, but you have to use -1, otherwise > > (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. Using `decode-time' does not retain the time zone name: (decode-time (encode-time '(0 30 12 15 1 2000 'ignored -1 "Africa/Juba"))) ; => (0 30 12 15 1 2000 6 nil 7200) The reason why I forced DST nil is hysteresis of glibc when dealing with DST transitions: (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) (0 0 23 3 2 2012 5 nil 7200) (0 0 23 3 3 2012 6 nil 7200) (0 0 0 4 4 2012 3 t 10800) (0 0 0 4 5 2012 5 t 10800) (0 0 0 4 6 2012 1 t 10800) (0 0 0 4 7 2012 3 t 10800) (0 0 0 4 8 2012 6 t 10800) (0 0 0 4 9 2012 2 t 10800) (0 0 0 4 10 2012 4 t 10800) (0 0 23 3 11 2012 6 nil 7200) (0 0 23 3 12 2012 1 nil 7200) Although, forcing DST nil will not always help here, so I need some other solution to this problem. (timezones, DSTs... :sigh:) >> + (decoded-time-dst time)) >> + (decoded-time-zone time)))))) >> + (if (not org-repeat-round-time) new-time > I am in doubts if `org-time-inc' should access `org-repeat-round-time' > directly or its value should be passed as an explicit argument. Perhaps > the additional argument may be optional with fallback to > `org-repeat-round-time' when it is omitted. This is of no use for now - we do not need to pass different parameters to `org-time-inc' from the existing Org code. But we can always add an extra optional argument if necessary. -- 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>
