bug#67706: 30.0.50; timer-next-integral-multiple-of-time does not account for different time-zones

bug#67706: 30.0.50; timer-next-integral-multiple-of-time does not account for different time-zones

[Bruno Boal]

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

bug#67706: 30.0.50; timer-next-integral-multiple-of-time does not account for different time-zones

[Eli Zaretskii]

> 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.

bug#67706: 30.0.50; timer-next-integral-multiple-of-time does not account for different time-zones

[Bruno Boal]

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.

bug#67706: 30.0.50; timer-next-integral-multiple-of-time does not account for different time-zones

[Eli Zaretskii]

> 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.

bug#67706: 30.0.50; timer-next-integral-multiple-of-time does not account for different time-zones

[Bruno Boal]

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.

bug#67706: 30.0.50; timer-next-integral-multiple-of-time does not account for different time-zones

[Eli Zaretskii]

> 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.

bug#67706: 30.0.50; timer-next-integral-multiple-of-time does not account for different time-zones

[Bruno Boal]

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

bug#67706: 30.0.50; timer-next-integral-multiple-of-time does not account for different time-zones

[Eli Zaretskii]

> 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.