From: Max Nikulin <manikulin@gmail.com>
To: emacs-orgmode@gnu.org
Subject: Re: [POLL] Dealing with +1m/y repeaters when jumping to impossible date (should 05-31 +1m be 07-01 or 06-30?)
Date: Wed, 15 May 2024 18:04:23 +0700 [thread overview]
Message-ID: <v224rp$m4l$1@ciao.gmane.io> (raw)
In-Reply-To: <87seykpn58.fsf@localhost>
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.
next prev parent reply other threads:[~2024-05-15 11:05 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-03-29 10:48 Leap-year bug with todo-cycle Anton Haglund
2024-04-05 18:34 ` [POLL] Dealing with +1m/y repeaters when jumping to impossible date (should 05-31 +1m be 07-01 or 06-30?) (was: Leap-year bug with todo-cycle) Ihor Radchenko
2024-04-05 19:53 ` Russell Adams
2024-04-05 21:18 ` jman
2024-04-05 21:27 ` Ihor Radchenko
2024-04-06 14:52 ` [POLL] Dealing with +1m/y repeaters when jumping to impossible date (should 05-31 +1m be 07-01 or 06-30?) Max Nikulin
2024-04-07 11:47 ` Ihor Radchenko
2024-05-13 10:07 ` [POLL] Dealing with +1m/y repeaters when jumping to impossible date (should 05-31 +1m be 07-01 or 06-30?) (was: Leap-year bug with todo-cycle) Ihor Radchenko
2024-05-14 11:08 ` [POLL] Dealing with +1m/y repeaters when jumping to impossible date (should 05-31 +1m be 07-01 or 06-30?) Max Nikulin
2024-05-14 12:56 ` Ihor Radchenko
2024-05-14 13:10 ` Stefan Nobis
2024-05-18 11:40 ` Ihor Radchenko
2024-05-18 12:49 ` Stefan Nobis
2024-05-18 13:09 ` Ihor Radchenko
2024-05-18 14:26 ` Stefan Nobis
2024-05-18 14:35 ` Ihor Radchenko
2024-05-15 11:04 ` Max Nikulin [this message]
2024-05-18 11:50 ` Ihor Radchenko
2024-05-16 10:41 ` Max Nikulin
2024-05-18 11:56 ` Ihor Radchenko
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.orgmode.org/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='v224rp$m4l$1@ciao.gmane.io' \
--to=manikulin@gmail.com \
--cc=emacs-orgmode@gnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).