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

Previous Next

Full log

Message #20 received at 67706 <at> debbugs.gnu.org (full text, mbox):

From: Bruno Boal <egomet <at> bboal.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 67706 <at> debbugs.gnu.org, info <at> protesilaos.com
Subject: Re: 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

Eli Zaretskii <eliz <at> gnu.org> writes:

>> From: Bruno Boal <egomet <at> bboal.com>
>> Cc: 67706 <at> debbugs.gnu.org, info <at> protesilaos.com
>> Date: Fri, 08 Dec 2023 16:51:03 +0000
>> 
>> Eli Zaretskii <eliz <at> gnu.org> writes:
>> 
>> >> Cc: info <at> protesilaos.com
>> >> From: Bruno Boal <egomet <at> 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.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.