* bug#67706: 30.0.50; timer-next-integral-multiple-of-time does not account for different time-zones
@ 2023-12-08 11:51 Bruno Boal
2023-12-08 12:44 ` Eli Zaretskii
0 siblings, 1 reply; 8+ messages in thread
From: Bruno Boal @ 2023-12-08 11:51 UTC (permalink / raw)
To: 67706; +Cc: info
Dear maintainers,
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?
Best regards and thank you in advanced,
Bruno and Protesilaos
In GNU Emacs 30.0.50 (build 1, x86_64-pc-linux-gnu, X toolkit, Xaw3d
scroll bars) of 2023-11-28 built on bb-hp-tiny
Repository revision: 7a5c91a2831602c3cd961158cf0b6a876852d7ac
Repository branch: master
Windowing system distributor 'The X.Org Foundation', version 11.0.12101009
System Description: Manjaro Linux
Configured using:
'configure --prefix=/usr --sysconfdir=/etc --libexecdir=/usr/lib
--localstatedir=/var --mandir=/usr/share/man --with-gameuser=:games
--with-modules --without-m17n-flt --without-gconf
--with-native-compilation=yes --with-xinput2 --with-x-toolkit=lucid
--with-xft --with-xaw3d --without-cairo --with-sound=no
--with-tree-sitter --without-gpm --without-compress-install
'--program-transform-name=s/\([ec]tags\)/\1.emacs/'
'CFLAGS=-march=x86-64 -mtune=generic -O2 -pipe -fno-plt -fexceptions
-Wp,-D_FORTIFY_SOURCE=2 -Wformat -Werror=format-security
-fstack-clash-protection -fcf-protection'
LDFLAGS=-Wl,-O1,--sort-common,--as-needed,-z,relro,-z,now'
Configured features:
ACL DBUS FREETYPE GIF GLIB GMP GNUTLS GSETTINGS HARFBUZZ JPEG JSON LCMS2
LIBOTF LIBSYSTEMD LIBXML2 MODULES NATIVE_COMP NOTIFY INOTIFY PDUMPER PNG
RSVG SECCOMP SQLITE3 THREADS TIFF TOOLKIT_SCROLL_BARS TREE_SITTER WEBP
X11 XAW3D XDBE XFT XIM XINPUT2 XPM LUCID ZLIB
Important settings:
value of $LC_COLLATE: C
value of $LC_MESSAGES: en_US.UTF-8
value of $LC_MONETARY: pt_PT.UTF-8
value of $LC_NUMERIC: pt_PT.UTF-8
value of $LC_TIME: pt_PT.UTF-8
value of $LANG: en_US.UTF-8
locale-coding-system: utf-8-unix
^ permalink raw reply [flat|nested] 8+ messages in thread
* bug#67706: 30.0.50; timer-next-integral-multiple-of-time does not account for different time-zones
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
0 siblings, 1 reply; 8+ messages in thread
From: Eli Zaretskii @ 2023-12-08 12:44 UTC (permalink / raw)
To: Bruno Boal; +Cc: 67706, info
> 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.
Thanks.
^ permalink raw reply [flat|nested] 8+ messages in thread
* bug#67706: 30.0.50; timer-next-integral-multiple-of-time does not account for different time-zones
2023-12-08 12:44 ` Eli Zaretskii
@ 2023-12-08 16:51 ` Bruno Boal
2023-12-08 19:29 ` Eli Zaretskii
0 siblings, 1 reply; 8+ messages in thread
From: Bruno Boal @ 2023-12-08 16:51 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: 67706, info
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.
Hope I've made my question clearer.
Thanks.
> Thanks.
^ permalink raw reply [flat|nested] 8+ messages in thread* bug#67706: 30.0.50; timer-next-integral-multiple-of-time does not account for different time-zones
2023-12-08 16:51 ` Bruno Boal
@ 2023-12-08 19:29 ` Eli Zaretskii
2023-12-08 19:45 ` Bruno Boal
0 siblings, 1 reply; 8+ messages in thread
From: Eli Zaretskii @ 2023-12-08 19:29 UTC (permalink / raw)
To: Bruno Boal; +Cc: 67706, info
> 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? If so, why is it
surprising that each system produces the same result in list-timers?
The argument 14400 means "14400 seconds from now", and is independent
of the time zone of the machine, since it's a relative time.
^ permalink raw reply [flat|nested] 8+ messages in thread
* bug#67706: 30.0.50; timer-next-integral-multiple-of-time does not account for different time-zones
2023-12-08 19:29 ` Eli Zaretskii
@ 2023-12-08 19:45 ` Bruno Boal
2023-12-08 20:45 ` Eli Zaretskii
0 siblings, 1 reply; 8+ messages in thread
From: Bruno Boal @ 2023-12-08 19:45 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: 67706, info
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.
^ permalink raw reply [flat|nested] 8+ messages in thread
* bug#67706: 30.0.50; timer-next-integral-multiple-of-time does not account for different time-zones
2023-12-08 19:45 ` Bruno Boal
@ 2023-12-08 20:45 ` Eli Zaretskii
2023-12-08 21:00 ` Bruno Boal
0 siblings, 1 reply; 8+ messages in thread
From: Eli Zaretskii @ 2023-12-08 20:45 UTC (permalink / raw)
To: Bruno Boal; +Cc: 67706, info
> From: Bruno Boal <egomet@bboal.com>
> Cc: 67706@debbugs.gnu.org, info@protesilaos.com
> Date: Fri, 08 Dec 2023 19:45:06 +0000
>
> (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.
The ELisp manual says:
In most cases, REPEAT has no effect on when _first_ call takes
place--TIME alone specifies that. There is one exception: if TIME
is ‘t’, then the timer runs whenever the time is a multiple of
REPEAT seconds after the epoch.
So I think time in this case is measured since the epoch, which is
independent of the time zone.
^ permalink raw reply [flat|nested] 8+ messages in thread* bug#67706: 30.0.50; timer-next-integral-multiple-of-time does not account for different time-zones
2023-12-08 20:45 ` Eli Zaretskii
@ 2023-12-08 21:00 ` Bruno Boal
2023-12-09 7:20 ` Eli Zaretskii
0 siblings, 1 reply; 8+ messages in thread
From: Bruno Boal @ 2023-12-08 21:00 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: 67706, info
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 19:45:06 +0000
>>
>> (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.
>
> The ELisp manual says:
>
>
> In most cases, REPEAT has no effect on when _first_ call takes
> place--TIME alone specifies that. There is one exception: if TIME
> is ‘t’, then the timer runs whenever the time is a multiple of
> REPEAT seconds after the epoch.
>
> So I think time in this case is measured since the epoch, which is
> independent of the time zone.
I see. So it's desired behavior and not a bug. We'll have to work around
it with code, since there's no option in run-at-time that fits our
needs.
Thank you for the explanation, it's a closed issue to me.
Best regards,
Bruno Boal
^ permalink raw reply [flat|nested] 8+ messages in thread
* bug#67706: 30.0.50; timer-next-integral-multiple-of-time does not account for different time-zones
2023-12-08 21:00 ` Bruno Boal
@ 2023-12-09 7:20 ` Eli Zaretskii
0 siblings, 0 replies; 8+ messages in thread
From: Eli Zaretskii @ 2023-12-09 7:20 UTC (permalink / raw)
To: Bruno Boal; +Cc: info, 67706-done
> From: Bruno Boal <egomet@bboal.com>
> Cc: 67706@debbugs.gnu.org, info@protesilaos.com
> Date: Fri, 08 Dec 2023 21:00:31 +0000
>
> Eli Zaretskii <eliz@gnu.org> writes:
>
> > The ELisp manual says:
> >
> >
> > In most cases, REPEAT has no effect on when _first_ call takes
> > place--TIME alone specifies that. There is one exception: if TIME
> > is ‘t’, then the timer runs whenever the time is a multiple of
> > REPEAT seconds after the epoch.
> >
> > So I think time in this case is measured since the epoch, which is
> > independent of the time zone.
>
> I see. So it's desired behavior and not a bug. We'll have to work around
> it with code, since there's no option in run-at-time that fits our
> needs.
>
> Thank you for the explanation, it's a closed issue to me.
Thanks, I'm therefore closing this bug.
^ permalink raw reply [flat|nested] 8+ messages in thread
end of thread, other threads:[~2023-12-09 7:20 UTC | newest]
Thread overview: 8+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
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
2023-12-08 20:45 ` Eli Zaretskii
2023-12-08 21:00 ` Bruno Boal
2023-12-09 7:20 ` Eli Zaretskii
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs.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).