From unknown Sun Jul 27 05:19:03 2025 X-Loop: help-debbugs@gnu.org Subject: bug#67706: 30.0.50; timer-next-integral-multiple-of-time does not account for different time-zones Resent-From: Bruno Boal Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Fri, 08 Dec 2023 12:36:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: report 67706 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: 67706@debbugs.gnu.org Cc: info@protesilaos.com X-Debbugs-Original-To: bug-gnu-emacs@gnu.org Received: via spool by submit@debbugs.gnu.org id=B.17020389321784 (code B ref -1); Fri, 08 Dec 2023 12:36:02 +0000 Received: (at submit) by debbugs.gnu.org; 8 Dec 2023 12:35:32 +0000 Received: from localhost ([127.0.0.1]:44081 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rBa4p-0000Sg-0T for submit@debbugs.gnu.org; Fri, 08 Dec 2023 07:35:32 -0500 Received: from lists.gnu.org ([2001:470:142::17]:54224) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rBZOT-0004Mu-5P for submit@debbugs.gnu.org; Fri, 08 Dec 2023 06:51:45 -0500 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 1rBZOA-0002r7-GV for bug-gnu-emacs@gnu.org; Fri, 08 Dec 2023 06:51:26 -0500 Received: from mout-p-102.mailbox.org ([80.241.56.152]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_CHACHA20_POLY1305:256) (Exim 4.90_1) (envelope-from ) id 1rBZO8-00041R-QK for bug-gnu-emacs@gnu.org; Fri, 08 Dec 2023 06:51:26 -0500 Received: from smtp1.mailbox.org (smtp1.mailbox.org [10.196.197.1]) (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-102.mailbox.org (Postfix) with ESMTPS id 4SmqGb2NPDz9sXk; Fri, 8 Dec 2023 12:51:03 +0100 (CET) From: Bruno Boal Date: Fri, 08 Dec 2023 11:51:01 +0000 Message-ID: <87msuk3obe.fsf@bboal.com> MIME-Version: 1.0 Content-Type: text/plain Received-SPF: pass client-ip=80.241.56.152; envelope-from=egomet@bboal.com; helo=mout-p-102.mailbox.org X-Spam_score_int: -25 X-Spam_score: -2.6 X-Spam_bar: -- X-Spam_report: (-2.6 / 5.0 requ) BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H5=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01 autolearn=ham autolearn_force=no X-Spam_action: no action X-Spam-Score: 1.0 (+) X-Mailman-Approved-At: Fri, 08 Dec 2023 07:35:30 -0500 X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.0 (/) 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 From unknown Sun Jul 27 05:19:03 2025 X-Loop: help-debbugs@gnu.org Subject: bug#67706: 30.0.50; timer-next-integral-multiple-of-time does not account for different time-zones Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Fri, 08 Dec 2023 12:46:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 67706 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Bruno Boal Cc: 67706@debbugs.gnu.org, info@protesilaos.com Received: via spool by 67706-submit@debbugs.gnu.org id=B67706.17020395042862 (code B ref 67706); Fri, 08 Dec 2023 12:46:01 +0000 Received: (at 67706) by debbugs.gnu.org; 8 Dec 2023 12:45:04 +0000 Received: from localhost ([127.0.0.1]:44101 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rBaE4-0000k5-DT for submit@debbugs.gnu.org; Fri, 08 Dec 2023 07:45:04 -0500 Received: from eggs.gnu.org ([2001:470:142:3::10]:48646) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rBaE1-0000jG-PT for 67706@debbugs.gnu.org; Fri, 08 Dec 2023 07:45:02 -0500 Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1rBaDh-0003BH-79; Fri, 08 Dec 2023 07:44:41 -0500 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date: mime-version; bh=21Rhe57qHoMbtbNOiiSM3EF40/4bBiYgrg7Knmr4mwc=; b=KxFbHAPMHoF0 6D+fX+wvOvnpdV6lYCLHZgDxdvgppiCazRWfUYdGooRd9ZCKqLZVZ+XGCHPAlf02itfWSduhnktuk 5UUiJIOxBdPyOsctab1txSHZju1I+WNP13/G2duGPbG4yk4RoPkimHmMXZ6ZIDzfhDhrvqNBlXg9M su2JdZ+QTtNmEy0njtXOlEYqSyS2PN+c+ZteQ9FcSUeNzyOev2cucD0DYeqDSvVOpTzPT/oImBKzH xTURX2FzJNJxPx12INhGt24JTnrLwQszeMd3mtVNyZHpGc47LcnvYIGj7HT1cPJN1ZCYS9ddfs6Vc JZJDP6fa7RfTroavxi1GoA==; Date: Fri, 08 Dec 2023 14:44:36 +0200 Message-Id: <83sf4czwwb.fsf@gnu.org> From: Eli Zaretskii In-Reply-To: <87msuk3obe.fsf@bboal.com> (message from Bruno Boal on Fri, 08 Dec 2023 11:51:01 +0000) References: <87msuk3obe.fsf@bboal.com> X-Spam-Score: -2.3 (--) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > 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. Thanks. From unknown Sun Jul 27 05:19:03 2025 X-Loop: help-debbugs@gnu.org Subject: bug#67706: 30.0.50; timer-next-integral-multiple-of-time does not account for different time-zones Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Fri, 08 Dec 2023 19:31:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 67706 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Bruno Boal Cc: 67706@debbugs.gnu.org, info@protesilaos.com Received: via spool by 67706-submit@debbugs.gnu.org id=B67706.17020638279986 (code B ref 67706); Fri, 08 Dec 2023 19:31:01 +0000 Received: (at 67706) by debbugs.gnu.org; 8 Dec 2023 19:30:27 +0000 Received: from localhost ([127.0.0.1]:46226 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rBgYM-0002b0-9m for submit@debbugs.gnu.org; Fri, 08 Dec 2023 14:30:26 -0500 Received: from eggs.gnu.org ([2001:470:142:3::10]:52718) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rBgYK-0002aV-6t for 67706@debbugs.gnu.org; Fri, 08 Dec 2023 14:30:25 -0500 Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1rBgXz-0000XG-IH; Fri, 08 Dec 2023 14:30:04 -0500 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date: mime-version; bh=/HNg1HSPA0KxripLfs+jUeBg7CRPofQPpxsySmHLAx4=; b=GJawzxD8SgbX JqFIgwL/SaH2v9/u76oLgIiQXjKsEYe1A0Nfn4X4zIQ8MjN7m6yWHu3dH3E0cpFeAK+oWhEb4cZBj 5mkf7Ih+p4PUL+RYdd7yve5NWGZlIfqzbh/QLlpcIYx3rLvcq0AcZrNjrneNNQXl/1JnVR6oiLoX6 dKsX/50FmGqxbQIoxoZ9cUQuVQ1OtPfAxP0LfVsp8h8ZjtI2rqaw0J8AHicJvTL+mIArWjiuLzsMo Fmgl+4kA93hr8kzOt5u2sW63HVOome4H1whq18ROTPvP4kDJIF3VYnzqcramIZzj3u2RbKfpKTtf4 qd1pAeSdRGd9vuNKgnd/bg==; Date: Fri, 08 Dec 2023 21:29:56 +0200 Message-Id: <83a5qkze4r.fsf@gnu.org> From: Eli Zaretskii In-Reply-To: <87il583afc.fsf@bboal.com> (message from Bruno Boal on Fri, 08 Dec 2023 16:51:03 +0000) References: <87msuk3obe.fsf@bboal.com> <83sf4czwwb.fsf@gnu.org> <87il583afc.fsf@bboal.com> X-Spam-Score: -2.3 (--) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > 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? 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. From unknown Sun Jul 27 05:19:03 2025 X-Loop: help-debbugs@gnu.org Subject: bug#67706: 30.0.50; timer-next-integral-multiple-of-time does not account for different time-zones Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Fri, 08 Dec 2023 20:47:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 67706 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Bruno Boal Cc: 67706@debbugs.gnu.org, info@protesilaos.com Received: via spool by 67706-submit@debbugs.gnu.org id=B67706.170206840712369 (code B ref 67706); Fri, 08 Dec 2023 20:47:02 +0000 Received: (at 67706) by debbugs.gnu.org; 8 Dec 2023 20:46:47 +0000 Received: from localhost ([127.0.0.1]:46302 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rBhkE-0003DR-T0 for submit@debbugs.gnu.org; Fri, 08 Dec 2023 15:46:47 -0500 Received: from eggs.gnu.org ([2001:470:142:3::10]:34662) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rBhkC-0003D5-9w for 67706@debbugs.gnu.org; Fri, 08 Dec 2023 15:46:45 -0500 Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1rBhjs-0005Mq-T3; Fri, 08 Dec 2023 15:46:25 -0500 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=MIME-version:References:Subject:In-Reply-To:To:From: Date; bh=NvVqSC8B0Xd0GM/3Y9x1NqZCZqNqCkZGwVtNMklWReg=; b=p0m7NSnGyp067XLB19Zp BfRrEXpkRE6srvDNSFnvPcuz6QKZr2mDbZ1KKjmXhbiMiU1fy82K+y3wEL7Sc3SdITgHQDcILi9xL kXdOolshQByCEl+s+/ccZ5UdTurhf6SCd3OkqlI726hByURiAshidvTheXbh7TW9tlGl2aggKrySZ wc/C7VXfywCjFyrrsq3NqQ6JZU6P1xGN3gJZdilxcMsf8/SWOTIqtCoUT37/gmURTKUw9cYoD03Cn aeMEjCmtaEi+jyVpvU+KcFOLG5tf16LsiLG4HB5h6At2Ro14VCo5LPdk9XkLWWnhvQVxQcOAZeYci PD0BJc2qKHmioA==; Date: Fri, 08 Dec 2023 22:45:50 +0200 Message-Id: <837clozam9.fsf@gnu.org> From: Eli Zaretskii In-Reply-To: <87fs0c32d9.fsf@bboal.com> (message from Bruno Boal on Fri, 08 Dec 2023 19:45:06 +0000) References: <87msuk3obe.fsf@bboal.com> <83sf4czwwb.fsf@gnu.org> <87il583afc.fsf@bboal.com> <83a5qkze4r.fsf@gnu.org> <87fs0c32d9.fsf@bboal.com> MIME-version: 1.0 Content-type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Spam-Score: -2.3 (--) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > From: Bruno Boal > 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. From unknown Sun Jul 27 05:19:03 2025 X-Loop: help-debbugs@gnu.org Subject: bug#67706: 30.0.50; timer-next-integral-multiple-of-time does not account for different time-zones Resent-From: Bruno Boal Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Fri, 08 Dec 2023 23:36:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 67706 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Eli Zaretskii Cc: 67706@debbugs.gnu.org, info@protesilaos.com Received: via spool by 67706-submit@debbugs.gnu.org id=B67706.17020785286972 (code B ref 67706); Fri, 08 Dec 2023 23:36:02 +0000 Received: (at 67706) by debbugs.gnu.org; 8 Dec 2023 23:35:28 +0000 Received: from localhost ([127.0.0.1]:46471 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rBkNT-0001oL-50 for submit@debbugs.gnu.org; Fri, 08 Dec 2023 18:35:27 -0500 Received: from mout-p-103.mailbox.org ([80.241.56.161]:47866) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rBe4U-0006Tq-43 for 67706@debbugs.gnu.org; Fri, 08 Dec 2023 11:51:30 -0500 Received: from smtp2.mailbox.org (smtp2.mailbox.org [IPv6:2001:67c:2050:b231:465::2]) (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-103.mailbox.org (Postfix) with ESMTPS id 4Smxwn3XcBz9sqq; Fri, 8 Dec 2023 17:51:05 +0100 (CET) From: Bruno Boal In-Reply-To: <83sf4czwwb.fsf@gnu.org> References: <87msuk3obe.fsf@bboal.com> <83sf4czwwb.fsf@gnu.org> Date: Fri, 08 Dec 2023 16:51:03 +0000 Message-ID: <87il583afc.fsf@bboal.com> MIME-Version: 1.0 Content-Type: text/plain X-Rspamd-Queue-Id: 4Smxwn3XcBz9sqq X-Spam-Score: -0.7 (/) 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 List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.7 (-) 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. Hope I've made my question clearer. Thanks. > Thanks. From unknown Sun Jul 27 05:19:03 2025 X-Loop: help-debbugs@gnu.org Subject: bug#67706: 30.0.50; timer-next-integral-multiple-of-time does not account for different time-zones 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 X-GNU-PR-Keywords: To: Eli Zaretskii Cc: 67706@debbugs.gnu.org, info@protesilaos.com Received: via spool by 67706-submit@debbugs.gnu.org id=B67706.17020785296992 (code B ref 67706); Fri, 08 Dec 2023 23:36:03 +0000 Received: (at 67706) by debbugs.gnu.org; 8 Dec 2023 23:35:29 +0000 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 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 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) From: Bruno Boal In-Reply-To: <83a5qkze4r.fsf@gnu.org> References: <87msuk3obe.fsf@bboal.com> <83sf4czwwb.fsf@gnu.org> <87il583afc.fsf@bboal.com> <83a5qkze4r.fsf@gnu.org> Date: Fri, 08 Dec 2023 19:45:06 +0000 Message-ID: <87fs0c32d9.fsf@bboal.com> MIME-Version: 1.0 Content-Type: text/plain X-Rspamd-Queue-Id: 4Sn1nc3MMMz9sq8 X-Spam-Score: -0.7 (/) 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 List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.7 (-) 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. From unknown Sun Jul 27 05:19:03 2025 X-Loop: help-debbugs@gnu.org Subject: bug#67706: 30.0.50; timer-next-integral-multiple-of-time does not account for different time-zones 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 X-GNU-PR-Keywords: To: Eli Zaretskii Cc: 67706@debbugs.gnu.org, info@protesilaos.com Received: via spool by 67706-submit@debbugs.gnu.org id=B67706.17020785306999 (code B ref 67706); Fri, 08 Dec 2023 23:36:03 +0000 Received: (at 67706) by debbugs.gnu.org; 8 Dec 2023 23:35:30 +0000 Received: from localhost ([127.0.0.1]:46477 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rBkNV-0001oj-L5 for submit@debbugs.gnu.org; Fri, 08 Dec 2023 18:35:30 -0500 Received: from mout-p-103.mailbox.org ([2001:67c:2050:0:465::103]:36946) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rBhxu-0003wf-D1 for 67706@debbugs.gnu.org; Fri, 08 Dec 2023 16:00:55 -0500 Received: from smtp2.mailbox.org (smtp2.mailbox.org [IPv6:2001:67c:2050:b231:465::2]) (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-103.mailbox.org (Postfix) with ESMTPS id 4Sn3Sd6cyJz9sSH; Fri, 8 Dec 2023 22:00:33 +0100 (CET) From: Bruno Boal In-Reply-To: <837clozam9.fsf@gnu.org> References: <87msuk3obe.fsf@bboal.com> <83sf4czwwb.fsf@gnu.org> <87il583afc.fsf@bboal.com> <83a5qkze4r.fsf@gnu.org> <87fs0c32d9.fsf@bboal.com> <837clozam9.fsf@gnu.org> Date: Fri, 08 Dec 2023 21:00:31 +0000 Message-ID: <87ttosz9xs.fsf@bboal.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Rspamd-Queue-Id: 4Sn3Sd6cyJz9sSH X-Spam-Score: -0.7 (/) 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 List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.7 (-) Eli Zaretskii writes: >> From: Bruno Boal >> Cc: 67706@debbugs.gnu.org, info@protesilaos.com >> Date: Fri, 08 Dec 2023 19:45:06 +0000 >>=20 >> (run-at-time TIME REPEAT FUNCTION &rest ARGS) >> ... >> TIME should be one of: ... >>=20 >> - a number of seconds from now; ;; The example you gave. Not applicable. >>=20 >> - 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 =E2=80=98t=E2=80=99, then the timer runs whenever the time is a m= ultiple 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 From unknown Sun Jul 27 05:19:03 2025 MIME-Version: 1.0 X-Mailer: MIME-tools 5.505 (Entity 5.505) X-Loop: help-debbugs@gnu.org From: help-debbugs@gnu.org (GNU bug Tracking System) To: Bruno Boal Subject: bug#67706: closed (Re: bug#67706: 30.0.50; timer-next-integral-multiple-of-time does not account for different time-zones) Message-ID: References: <835y17zvt3.fsf@gnu.org> <87msuk3obe.fsf@bboal.com> X-Gnu-PR-Message: they-closed 67706 X-Gnu-PR-Package: emacs Reply-To: 67706@debbugs.gnu.org Date: Sat, 09 Dec 2023 07:22:01 +0000 Content-Type: multipart/mixed; boundary="----------=_1702106521-2324-1" This is a multi-part message in MIME format... ------------=_1702106521-2324-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" Your bug report #67706: 30.0.50; timer-next-integral-multiple-of-time does not account for = different time-zones which was filed against the emacs package, has been closed. The explanation is attached below, along with your original report. If you require more details, please reply to 67706@debbugs.gnu.org. --=20 67706: https://debbugs.gnu.org/cgi/bugreport.cgi?bug=3D67706 GNU Bug Tracking System Contact help-debbugs@gnu.org with problems ------------=_1702106521-2324-1 Content-Type: message/rfc822 Content-Disposition: inline Content-Transfer-Encoding: 7bit Received: (at 67706-done) by debbugs.gnu.org; 9 Dec 2023 07:21:04 +0000 Received: from localhost ([127.0.0.1]:46705 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rBre4-0000a2-0K for submit@debbugs.gnu.org; Sat, 09 Dec 2023 02:21:04 -0500 Received: from eggs.gnu.org ([2001:470:142:3::10]:46514) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rBre1-0000ZM-H5 for 67706-done@debbugs.gnu.org; Sat, 09 Dec 2023 02:21:02 -0500 Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1rBrdh-0006Hv-9o; Sat, 09 Dec 2023 02:20:41 -0500 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=MIME-version:References:Subject:In-Reply-To:To:From: Date; bh=c1t5A39AzmcAwoq8bNGaqS1ALAAKNMz3Uru9287tphU=; b=F+/0gB6fYMLIv+YxMpLl s0T5mmU/Gs3R12LecDwCP87G4xX/yKVb71LDPzEPCCHsgOf6sLVXcVCgWfq9Xcxfxssog+VUhwkxc t/MN5cxzNbCieoWZAPGWB7PMNcZXPldZ7lq8vJ/SKpo1zKaA2tZ9BM7UBoHRLlIOiNxhbKzSp1iQp pqB4Z38s4HXHAbMMLnmI5hZksl7U86IMvlUriZMcNpfTu8rEQHYS6B/FxHyK/BDkuei1bcNjntSFH TzwhVpDl+pE46at0+oCWcLFggVU1UUv5v/GWzqh9tfCAsU3lUi3dvgmF3/gM4pwR/LuQhiOL31kxI i6+JP+B0723Q1A==; Date: Sat, 09 Dec 2023 09:20:24 +0200 Message-Id: <835y17zvt3.fsf@gnu.org> From: Eli Zaretskii To: Bruno Boal In-Reply-To: <87ttosz9xs.fsf@bboal.com> (message from Bruno Boal on Fri, 08 Dec 2023 21:00:31 +0000) Subject: Re: bug#67706: 30.0.50; timer-next-integral-multiple-of-time does not account for different time-zones References: <87msuk3obe.fsf@bboal.com> <83sf4czwwb.fsf@gnu.org> <87il583afc.fsf@bboal.com> <83a5qkze4r.fsf@gnu.org> <87fs0c32d9.fsf@bboal.com> <837clozam9.fsf@gnu.org> <87ttosz9xs.fsf@bboal.com> MIME-version: 1.0 Content-type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 67706-done Cc: info@protesilaos.com, 67706-done@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > From: Bruno Boal > Cc: 67706@debbugs.gnu.org, info@protesilaos.com > Date: Fri, 08 Dec 2023 21:00:31 +0000 > > Eli Zaretskii 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. ------------=_1702106521-2324-1 Content-Type: message/rfc822 Content-Disposition: inline Content-Transfer-Encoding: 7bit Received: (at submit) by debbugs.gnu.org; 8 Dec 2023 12:35:32 +0000 Received: from localhost ([127.0.0.1]:44081 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rBa4p-0000Sg-0T for submit@debbugs.gnu.org; Fri, 08 Dec 2023 07:35:32 -0500 Received: from lists.gnu.org ([2001:470:142::17]:54224) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rBZOT-0004Mu-5P for submit@debbugs.gnu.org; Fri, 08 Dec 2023 06:51:45 -0500 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 1rBZOA-0002r7-GV for bug-gnu-emacs@gnu.org; Fri, 08 Dec 2023 06:51:26 -0500 Received: from mout-p-102.mailbox.org ([80.241.56.152]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_CHACHA20_POLY1305:256) (Exim 4.90_1) (envelope-from ) id 1rBZO8-00041R-QK for bug-gnu-emacs@gnu.org; Fri, 08 Dec 2023 06:51:26 -0500 Received: from smtp1.mailbox.org (smtp1.mailbox.org [10.196.197.1]) (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-102.mailbox.org (Postfix) with ESMTPS id 4SmqGb2NPDz9sXk; Fri, 8 Dec 2023 12:51:03 +0100 (CET) From: Bruno Boal To: bug-gnu-emacs@gnu.org Subject: 30.0.50; timer-next-integral-multiple-of-time does not account for different time-zones Date: Fri, 08 Dec 2023 11:51:01 +0000 Message-ID: <87msuk3obe.fsf@bboal.com> MIME-Version: 1.0 Content-Type: text/plain Received-SPF: pass client-ip=80.241.56.152; envelope-from=egomet@bboal.com; helo=mout-p-102.mailbox.org X-Spam_score_int: -25 X-Spam_score: -2.6 X-Spam_bar: -- X-Spam_report: (-2.6 / 5.0 requ) BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H5=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01 autolearn=ham autolearn_force=no X-Spam_action: no action X-Spam-Score: 1.0 (+) X-Debbugs-Envelope-To: submit X-Mailman-Approved-At: Fri, 08 Dec 2023 07:35:30 -0500 Cc: info@protesilaos.com X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.0 (/) 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 ------------=_1702106521-2324-1--