From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Bruno Boal Newsgroups: gmane.emacs.bugs 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 Message-ID: <87fs0c32d9.fsf@bboal.com> References: <87msuk3obe.fsf@bboal.com> <83sf4czwwb.fsf@gnu.org> <87il583afc.fsf@bboal.com> <83a5qkze4r.fsf@gnu.org> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="22807"; mail-complaints-to="usenet@ciao.gmane.io" Cc: 67706@debbugs.gnu.org, info@protesilaos.com To: Eli Zaretskii Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Sat Dec 09 00:36:40 2023 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1rBkOe-0005k6-1i for geb-bug-gnu-emacs@m.gmane-mx.org; Sat, 09 Dec 2023 00:36:40 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1rBkNs-0001bK-31; Fri, 08 Dec 2023 18:35:52 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1rBkNq-0001aW-Hg for bug-gnu-emacs@gnu.org; Fri, 08 Dec 2023 18:35:50 -0500 Original-Received: from debbugs.gnu.org ([2001:470:142:5::43]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1rBkNq-00022I-7F for bug-gnu-emacs@gnu.org; Fri, 08 Dec 2023 18:35:50 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1rBkO3-0001qF-CJ for bug-gnu-emacs@gnu.org; Fri, 08 Dec 2023 18:36:03 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Bruno Boal Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Fri, 08 Dec 2023 23:36:03 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 67706 X-GNU-PR-Package: emacs Original-Received: via spool by 67706-submit@debbugs.gnu.org id=B67706.17020785296992 (code B ref 67706); Fri, 08 Dec 2023 23:36:03 +0000 Original-Received: (at 67706) by debbugs.gnu.org; 8 Dec 2023 23:35:29 +0000 Original-Received: from localhost ([127.0.0.1]:46475 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rBkNU-0001oY-Pv for submit@debbugs.gnu.org; Fri, 08 Dec 2023 18:35:29 -0500 Original-Received: from mout-p-201.mailbox.org ([2001:67c:2050:0:465::201]:55652) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rBgmw-0003Hs-Ra for 67706@debbugs.gnu.org; Fri, 08 Dec 2023 14:45:31 -0500 Original-Received: from smtp102.mailbox.org (smtp102.mailbox.org [IPv6:2001:67c:2050:b231:465::102]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by mout-p-201.mailbox.org (Postfix) with ESMTPS id 4Sn1nc3MMMz9sq8; Fri, 8 Dec 2023 20:45:08 +0100 (CET) In-Reply-To: <83a5qkze4r.fsf@gnu.org> X-Rspamd-Queue-Id: 4Sn1nc3MMMz9sq8 X-Mailman-Approved-At: Fri, 08 Dec 2023 18:35:26 -0500 X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Original-Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.bugs:275817 Archived-At: Eli Zaretskii writes: >> From: Bruno Boal >> Cc: 67706@debbugs.gnu.org, info@protesilaos.com >> Date: Fri, 08 Dec 2023 16:51:03 +0000 >> >> Eli Zaretskii writes: >> >> >> Cc: info@protesilaos.com >> >> From: Bruno Boal >> >> 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.