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

View this message in rfc822 format

From: help-debbugs <at> gnu.org (GNU bug Tracking System)
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: tracker <at> debbugs.gnu.org
Subject: bug#67706: closed (30.0.50; timer-next-integral-multiple-of-time
 does not account for different time-zones)
Date: Sat, 09 Dec 2023 07:22:01 +0000

[Message part 1 (text/plain, inline)]

Your message dated Sat, 09 Dec 2023 09:20:24 +0200
with message-id <835y17zvt3.fsf <at> gnu.org>
and subject line Re: bug#67706: 30.0.50; timer-next-integral-multiple-of-time does not account for different time-zones
has caused the debbugs.gnu.org bug report #67706,
regarding 30.0.50; timer-next-integral-multiple-of-time does not account for different time-zones
to be marked as done.

(If you believe you have received this mail in error, please contact
help-debbugs <at> gnu.org.)


-- 
67706: https://debbugs.gnu.org/cgi/bugreport.cgi?bug=67706
GNU Bug Tracking System
Contact help-debbugs <at> gnu.org with problems

[Message part 2 (message/rfc822, inline)]

From: Bruno Boal <egomet <at> bboal.com>
To: bug-gnu-emacs <at> gnu.org
Cc: info <at> protesilaos.com
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

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

[Message part 3 (message/rfc822, inline)]

From: Eli Zaretskii <eliz <at> gnu.org>
To: Bruno Boal <egomet <at> bboal.com>
Cc: info <at> protesilaos.com, 67706-done <at> debbugs.gnu.org
Subject: Re: bug#67706: 30.0.50; timer-next-integral-multiple-of-time does
 not account for different time-zones
Date: Sat, 09 Dec 2023 09:20:24 +0200

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

Previous Next

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