From: Bruno Boal <egomet@bboal.com>
To: Eli Zaretskii <eliz@gnu.org>
Cc: 67706@debbugs.gnu.org, info@protesilaos.com
Subject: bug#67706: 30.0.50; timer-next-integral-multiple-of-time does not account for different time-zones
Date: Fri, 08 Dec 2023 19:45:06 +0000 [thread overview]
Message-ID: <87fs0c32d9.fsf@bboal.com> (raw)
In-Reply-To: <83a5qkze4r.fsf@gnu.org>
Eli Zaretskii <eliz@gnu.org> writes:
>> From: Bruno Boal <egomet@bboal.com>
>> Cc: 67706@debbugs.gnu.org, info@protesilaos.com
>> Date: Fri, 08 Dec 2023 16:51:03 +0000
>>
>> Eli Zaretskii <eliz@gnu.org> writes:
>>
>> >> Cc: info@protesilaos.com
>> >> From: Bruno Boal <egomet@bboal.com>
>> >> Date: Fri, 08 Dec 2023 11:51:01 +0000
>> >>
>> >> While trying the following snippet in both Lisbon and Athens, we
>> >> get the same timer object as showed in list-timers.
>> >>
>> >> (run-at-time t 14400 #'message "Testing")
>> >>
>> >> What we would expect, is two different timer objects accounting for the
>> >> different time zones.
>> >>
>> >> We did a edebug and found out that the function aforementioned on the
>> >> subject is always returning the same value despite of the different
>> >> local times.
>> >>
>> >> Are we missing something obvious or is this a bug?
>> >
>> > Please show a minimal recipe, starting from "emacs -Q", to reproduce
>> > the issue you are seeing. I'm not sure I understand all the details,
>> > and therefore don't follow why you expected two objects.
>>
>> Let me try to demonstrate the possible issue.
>>
>> Running the following snippet in my PC, with Lisbon time of 16h36:
>>
>> (run-at-time t 14400 #'message "Testing")
>>
>> Checking result of `list-timers' function:
>>
>> Next Repeat Function
>> 3h 24m 34.7s 4h message
>>
>> Running the same snippet in Prot's PC, with Athens time of 18h36:
>>
>> (run-at-time t 14400 #'message "Testing")
>>
>> Checking result of `list-timers' function:
>>
>> Next Repeat Function
>> 3h 24m 34.7s 4h message
>>
>> So despite the difference of time-zones the next occurrence of Function
>> has the same Next time interval. Is this the expected behavior? Because
>> reading the documentation I would expect the Function to have a Next
>> interval multiple of Repeat in order to run at 20h local time of the
>> machine where the code was evaluated. Being this the case, the Next
>> value in Prot's PC would have to be 1h 24m34.7s.
>
> Sorry, I still don't follow: these are two separate systems set up
> with two different time zones, is that right?
Correct.
> If so, why is it surprising that each system produces the same result
> in list-timers?
Because we are running (run-at-time t 14400 ...) and not (run-at-time
14400 ...)
> The argument 14400 means "14400 seconds from now", and is independent
> of the time zone of the machine, since it's a relative time.
Only if its the first argument of the function.
According to the documentation:
(run-at-time TIME REPEAT FUNCTION &rest ARGS)
...
TIME should be one of: ...
- a number of seconds from now; ;; The example you gave. Not applicable.
- or t (with non-nil REPEAT) meaning the next integral multiple of
REPEAT. This is handy when you want the function to run at a certain
"round" number. For instance, (run-at-time t 60 ...) will run at
11:04:00, 11:05:00, etc. ;; My example.
If I run now, at 19h40 my time, the example snippet, the FUNCTION will
be run in 20m, at 20h and not in 4h from now. That is because 20h is a
multiple of 14400 secs (4h).
Again, I might be seeing this incorrectly somehow, but I want to make
sure that you understand our question.
Thanks again.
next prev parent reply other threads:[~2023-12-08 19:45 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-12-08 11:51 bug#67706: 30.0.50; timer-next-integral-multiple-of-time does not account for different time-zones Bruno Boal
2023-12-08 12:44 ` Eli Zaretskii
2023-12-08 16:51 ` Bruno Boal
2023-12-08 19:29 ` Eli Zaretskii
2023-12-08 19:45 ` Bruno Boal [this message]
2023-12-08 20:45 ` Eli Zaretskii
2023-12-08 21:00 ` Bruno Boal
2023-12-09 7:20 ` Eli Zaretskii
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
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87fs0c32d9.fsf@bboal.com \
--to=egomet@bboal.com \
--cc=67706@debbugs.gnu.org \
--cc=eliz@gnu.org \
--cc=info@protesilaos.com \
/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 external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.