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 #23 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 21:00:31 +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 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

Previous Next

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