GNU bug report logs - #79437
30.2; world-clock silently and incorrectly parses invalid time zone

Previous Next

To reply to this bug, email your comments to 79437 AT debbugs.gnu.org.

Toggle the display of automated, internal messages from the tracker.

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

From: "Jorge P. de Morais Neto" <jorge+git <at> disr.it>
To: bug-gnu-emacs <at> gnu.org
Subject: 30.2; world-clock silently and incorrectly parses invalid time zone
Date: Fri, 12 Sep 2025 13:04:32 -0300

Hello, Emacs comrades!

From `emacs -Q':

1. Invoke M-x world-clock to load the required Elisp libraries
2. Customize `zoneinfo-style-world-list' to "(("Europe/Pisa" "Pisa"))".
   Set for session.
3. Invoke M-x world-clock again.
4. It says "Pisa sexta 12 setembro 15:50 Europe" (current time is 15:50
   UTC).

I asked a friend in Pisa the local time and he reported the error.  I
then realized world-clock said "Europe" instead of "Europe/Pisa".  I
suspected "Europe/Pisa" is an invalid timezone name, so I looked into
Gnome settings widget, and indeed Italy's only timezone is
"Europe/Rome".  I then fixed `zoneinfo-style-world-list'.

Emacs /silently/ parsed "Europe/Pisa" as "Europe", inducing the user
into error.  Yes, a previous user error caused the situation, but modern
UX should detect and report predictable user errors, and typing an
invalid timezone name is pretty predictable.

Kind regards,
  Jorge

In GNU Emacs 30.2 (build 1, x86_64-pc-linux-gnu, GTK+ Version 3.24.49,
 cairo version 1.18.4) of 2025-08-14 built on localhost
System Description: Gentoo Linux

Configured using:
 'configure --prefix=/usr --build=x86_64-pc-linux-gnu
 --host=x86_64-pc-linux-gnu --mandir=/usr/share/man
 --infodir=/usr/share/info --datadir=/usr/share --sysconfdir=/etc
 --localstatedir=/var/lib --datarootdir=/usr/share
 --disable-silent-rules --docdir=/usr/share/doc/emacs-30.2
 --htmldir=/usr/share/doc/emacs-30.2/html --libdir=/usr/lib64
 --program-suffix=-emacs-30 --includedir=/usr/include/emacs-30
 --infodir=/usr/share/info/emacs-30 --localstatedir=/var
 --enable-locallisppath=/etc/emacs:/usr/share/emacs/site-lisp
 --without-compress-install --without-hesiod --without-pop
 --with-file-notification=inotify --with-pdumper --enable-acl
 --enable-xattr --with-dbus --with-modules --without-gameuser
 --with-libgmp --with-gpm --with-native-compilation=aot
 --without-kerberos --without-kerberos5 --with-lcms2 --with-xml2
 --with-mailutils --without-selinux --with-sqlite3 --with-gnutls
 --with-libsystemd --with-threads --with-tree-sitter --without-wide-int
 --with-sound=alsa --with-zlib --with-pgtk --without-x --without-ns
 --with-toolkit-scroll-bars --without-gconf --without-xwidgets
 --without-gsettings --with-harfbuzz --without-libotf --without-m17n-flt
 --with-gif --with-jpeg --with-png --with-rsvg --with-tiff --with-webp
 --with-imagemagick --with-dumping=pdumper 'CFLAGS=-march=native -O2
 -fvect-cost-model=cheap -flto -pipe -Werror=odr
 -Werror=lto-type-mismatch -Werror=strict-aliasing -fno-fast-math
 -ffp-contract=off' 'CPPFLAGS= -DUSE_VALGRIND=no' 'LDFLAGS=-march=native
 -O2 -fvect-cost-model=cheap -flto -pipe -Werror=odr
 -Werror=lto-type-mismatch -Werror=strict-aliasing -Wl,-O1
 -Wl,--as-needed -Wl,-z,pack-relative-relocs''

Configured features:
ACL CAIRO DBUS FREETYPE GIF GLIB GMP GNUTLS GPM HARFBUZZ IMAGEMAGICK
JPEG LCMS2 LIBSYSTEMD LIBXML2 MODULES NATIVE_COMP NOTIFY INOTIFY PDUMPER
PGTK PNG RSVG SECCOMP SOUND SQLITE3 THREADS TIFF TOOLKIT_SCROLL_BARS
TREE_SITTER WEBP XIM GTK3 ZLIB

Important settings:
  value of $EMACSLOADPATH: /home/jorge/.guix-profile/share/emacs/site-lisp:
  value of $LC_MONETARY: pt_BR.UTF-8
  value of $LC_NUMERIC: pt_BR.UTF-8
  value of $LC_TIME: pt_BR.UTF-8
  value of $LANG: en_US.UTF-8
  value of $XMODIFIERS: @im=ibus
  locale-coding-system: utf-8-unix

Major mode: World clock

Minor modes in effect:
  tooltip-mode: t
  global-eldoc-mode: t
  show-paren-mode: t
  electric-indent-mode: t
  mouse-wheel-mode: t
  tool-bar-mode: t
  menu-bar-mode: t
  file-name-shadow-mode: t
  global-font-lock-mode: t
  font-lock-mode: t
  blink-cursor-mode: t
  minibuffer-regexp-mode: t
  buffer-read-only: t
  line-number-mode: t
  indent-tabs-mode: t
  transient-mark-mode: t
  auto-composition-mode: t
  auto-encryption-mode: t
  auto-compression-mode: t

Load-path shadows:
None found.

Features:
(shadow sort mail-extr emacsbug message mailcap yank-media puny dired
dired-loaddefs rfc822 mml mml-sec password-cache epa derived epg rfc6068
epg-config gnus-util text-property-search time-date subr-x mm-decode
mm-bodies mm-encode mail-parse rfc2231 mailabbrev gmm-utils mailheader
sendmail rfc2047 rfc2045 ietf-drums mm-util mail-prsvr mail-utils tabify
thingatpt help-fns radix-tree help-mode cus-edit pp cus-start cus-load
icons wid-edit cl-loaddefs cl-lib time rmc iso-transl tooltip cconv
eldoc paren electric uniquify ediff-hook vc-hooks lisp-float-type
elisp-mode mwheel term/pgtk-win pgtk-win term/common-win touch-screen
pgtk-dnd tool-bar dnd fontset image regexp-opt fringe tabulated-list
replace newcomment text-mode lisp-mode prog-mode register page tab-bar
menu-bar rfn-eshadow isearch easymenu timer select scroll-bar mouse
jit-lock font-lock syntax font-core term/tty-colors frame minibuffer
nadvice seq simple cl-generic indonesian philippine cham georgian
utf-8-lang misc-lang vietnamese tibetan thai tai-viet lao korean
japanese eucjp-ms cp51932 hebrew greek romanian slovak czech european
ethiopic indian cyrillic chinese composite emoji-zwj charscript charprop
case-table epa-hook jka-cmpr-hook help abbrev obarray oclosure
cl-preloaded button loaddefs theme-loaddefs faces cus-face macroexp
files window text-properties overlay sha1 md5 base64 format env
code-pages mule custom widget keymap hashtable-print-readable backquote
threads dbusbind inotify dynamic-setting font-render-setting cairo gtk
pgtk lcms2 multi-tty move-toolbar make-network-process native-compile
emacs)

Memory information:
((conses 16 82756 9452) (symbols 48 8099 0) (strings 32 20847 2155)
 (string-bytes 1 616667) (vectors 16 11102)
 (vector-slots 8 152004 9768) (floats 8 32 38) (intervals 56 410 23)
 (buffers 992 14))

-- 
- We live in capitalism.  Its power seems inescapable.  So did the
  divine right of kings. (Ursula K. Le Guin)

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: "Jorge P. de Morais Neto" <jorge+git <at> disr.it>,
 Paul Eggert <eggert <at> cs.ucla.edu>
Cc: 79437 <at> debbugs.gnu.org
Subject: Re: bug#79437: 30.2;
 world-clock silently and incorrectly parses invalid time zone
Date: Sat, 13 Sep 2025 09:31:30 +0300

> From: "Jorge P. de Morais Neto" <jorge+git <at> disr.it>
> Date: Fri, 12 Sep 2025 13:04:32 -0300
> 
> >From `emacs -Q':
> 
> 1. Invoke M-x world-clock to load the required Elisp libraries
> 2. Customize `zoneinfo-style-world-list' to "(("Europe/Pisa" "Pisa"))".
>    Set for session.
> 3. Invoke M-x world-clock again.
> 4. It says "Pisa sexta 12 setembro 15:50 Europe" (current time is 15:50
>    UTC).
> 
> I asked a friend in Pisa the local time and he reported the error.  I
> then realized world-clock said "Europe" instead of "Europe/Pisa".  I
> suspected "Europe/Pisa" is an invalid timezone name, so I looked into
> Gnome settings widget, and indeed Italy's only timezone is
> "Europe/Rome".  I then fixed `zoneinfo-style-world-list'.
> 
> Emacs /silently/ parsed "Europe/Pisa" as "Europe", inducing the user
> into error.  Yes, a previous user error caused the situation, but modern
> UX should detect and report predictable user errors, and typing an
> invalid timezone name is pretty predictable.

AFAIU, it isn't Emacs that silently interprets "Europe/Pisa" as
"Europe", it's your libc time-related functions.  I believe specifying
a non-existent file in timezone invokes undefined behavior, but maybe
Paul has more specific information about that.

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

From: Paul Eggert <eggert <at> cs.ucla.edu>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 79437 <at> debbugs.gnu.org, "Jorge P. de Morais Neto" <jorge+git <at> disr.it>
Subject: Re: bug#79437: 30.2; world-clock silently and incorrectly parses
 invalid time zone
Date: Sat, 13 Sep 2025 07:57:39 -0700

On 2025-09-12 23:31, Eli Zaretskii wrote:
> I believe specifying
> a non-existent file in timezone invokes undefined behavior

On NetBSD, which has native tzalloc, Emacs signals an error "invalid 
time zone specification".

On other platforms POSIX does not define the behavior, but it's UTC on 
all platforms I know of. In the extremely rare case where wall clock 
time_t (contrary to POSIX) counts leap seconds, it may be UTC without 
leap seconds. The time zone abbreviation is platform-dependent; some 
platforms use "-00", some "UTC", some "GMT", some a string derived from 
TZ's value. My guess is that Jorge's friend's platform used the last 
approach, and used the abbreviation "Europe" which it derived from 
"Europe/Pisa".

We could modify Gnulib's tzalloc to try to detect this situation and 
behave more like native tzalloc. It wouldn't be that easy, though, and 
I'm not sure it's worth the hassle.

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Paul Eggert <eggert <at> cs.ucla.edu>
Cc: 79437 <at> debbugs.gnu.org, jorge+git <at> disr.it
Subject: Re: bug#79437: 30.2; world-clock silently and incorrectly parses
 invalid time zone
Date: Sat, 13 Sep 2025 18:02:16 +0300

> Date: Sat, 13 Sep 2025 07:57:39 -0700
> Cc: 79437 <at> debbugs.gnu.org, "Jorge P. de Morais Neto" <jorge+git <at> disr.it>
> From: Paul Eggert <eggert <at> cs.ucla.edu>
> 
> On 2025-09-12 23:31, Eli Zaretskii wrote:
> > I believe specifying
> > a non-existent file in timezone invokes undefined behavior
> 
> On NetBSD, which has native tzalloc, Emacs signals an error "invalid 
> time zone specification".
> 
> On other platforms POSIX does not define the behavior, but it's UTC on 
> all platforms I know of. In the extremely rare case where wall clock 
> time_t (contrary to POSIX) counts leap seconds, it may be UTC without 
> leap seconds. The time zone abbreviation is platform-dependent; some 
> platforms use "-00", some "UTC", some "GMT", some a string derived from 
> TZ's value. My guess is that Jorge's friend's platform used the last 
> approach, and used the abbreviation "Europe" which it derived from 
> "Europe/Pisa".
> 
> We could modify Gnulib's tzalloc to try to detect this situation and 
> behave more like native tzalloc. It wouldn't be that easy, though, and 
> I'm not sure it's worth the hassle.

Me neither.  Wouldn't such a test be expensive (scan the entire
timezone DB)?

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

From: Paul Eggert <eggert <at> cs.ucla.edu>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 79437 <at> debbugs.gnu.org, jorge+git <at> disr.it
Subject: Re: bug#79437: 30.2; world-clock silently and incorrectly parses
 invalid time zone
Date: Sat, 13 Sep 2025 08:05:55 -0700

On 2025-09-13 08:02, Eli Zaretskii wrote:
> Wouldn't such a test be expensive (scan the entire
> timezone DB)?

No, as we merely need to check whether the TZ setting matches a time 
zone file. (This is for the typical case where each named time zone has 
a file; Android would be different.)

Yeah, probably not worth the hassle.

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

From: Jorge P. de Morais Neto <jorge+git <at> disr.it>
To: Paul Eggert <eggert <at> cs.ucla.edu>, Eli Zaretskii <eliz <at> gnu.org>
Cc: 79437 <at> debbugs.gnu.org
Subject: Re: bug#79437: 30.2; world-clock silently and incorrectly parses
 invalid time zone
Date: Sat, 13 Sep 2025 20:42:09 -0300

Hi.  A small clarification below:

Em [2025-09-13 sáb 07:57:39-0700], Paul Eggert escreveu:

> My guess is that Jorge's friend's platform used the last approach, and
> used the abbreviation "Europe" which it derived from "Europe/Pisa".

My friend does not use Emacs.  He simply told me the correct local time.
I am the Emacs user, and I am on Gentoo GNU/Linux.

Regards

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

From: Jorge P. de Morais Neto <jorge+git <at> disr.it>
To: Paul Eggert <eggert <at> cs.ucla.edu>, Eli Zaretskii <eliz <at> gnu.org>
Cc: 79437 <at> debbugs.gnu.org
Subject: Re: bug#79437: 30.2; world-clock silently and incorrectly parses
 invalid time zone
Date: Sat, 13 Sep 2025 20:56:44 -0300

Hi.  I reply below:

Em [2025-09-13 sáb 08:05:55-0700], Paul Eggert escreveu:

> No, as we merely need to check whether the TZ setting matches a time
> zone file. (This is for the typical case where each named time zone
> has a file; Android would be different.)
>
> Yeah, probably not worth the hassle.

I am an IT infrastructure analyst and not a software developer, so I am
unsure whether to opine on the bug's solution, but what "hassle" are you
talking about?

A. Development time;
B. code complexity; or
C. runtime cost?

Anyway, I see many possible solutions and workarounds:

1. `world-clock' could check the timezone name is valid, and warn in
   case it is not.
2. custom.el could validate `zoneinfo-style-world-list' when it is set.
3. The docstring of `zoneinfo-style-world-list' and `world-clock' could
   warn the user about the problem.

I believe 3 should be implemented in any case.  Ideally it would be
combined with 1, 2, or preferably both.

Kind regards!

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

From: Paul Eggert <eggert <at> cs.ucla.edu>
To: "Jorge P. de Morais Neto" <jorge+git <at> disr.it>, Eli Zaretskii <eliz <at> gnu.org>
Cc: 79437 <at> debbugs.gnu.org
Subject: Re: bug#79437: 30.2; world-clock silently and incorrectly parses
 invalid time zone
Date: Sat, 13 Sep 2025 21:55:07 -0700

On 2025-09-13 16:56, Jorge P. de Morais Neto wrote:

> Anyway, I see many possible solutions and workarounds:
> 
> 1. `world-clock' could check the timezone name is valid, and warn in
>     case it is not.
> 2. custom.el could validate `zoneinfo-style-world-list' when it is set.
> 3. The docstring of `zoneinfo-style-world-list' and `world-clock' could
>     warn the user about the problem.
> 
> I believe 3 should be implemented in any case.  Ideally it would be
> combined with 1, 2, or preferably both.

That all sounds reasonable, if someone else wants to implement and/or 
document it.

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Jorge P. de Morais Neto <jorge+git <at> disr.it>
Cc: 79437 <at> debbugs.gnu.org, eggert <at> cs.ucla.edu
Subject: Re: bug#79437: 30.2; world-clock silently and incorrectly parses
 invalid time zone
Date: Sun, 14 Sep 2025 08:24:45 +0300

> From: Jorge P. de Morais Neto <jorge+git <at> disr.it>
> Cc: 79437 <at> debbugs.gnu.org
> Date: Sat, 13 Sep 2025 20:56:44 -0300
> 
> Hi.  I reply below:
> 
> Em [2025-09-13 sáb 08:05:55-0700], Paul Eggert escreveu:
> 
> > No, as we merely need to check whether the TZ setting matches a time
> > zone file. (This is for the typical case where each named time zone
> > has a file; Android would be different.)
> >
> > Yeah, probably not worth the hassle.
> 
> I am an IT infrastructure analyst and not a software developer, so I am
> unsure whether to opine on the bug's solution, but what "hassle" are you
> talking about?
> 
> A. Development time;
> B. code complexity; or
> C. runtime cost?
> 
> Anyway, I see many possible solutions and workarounds:
> 
> 1. `world-clock' could check the timezone name is valid, and warn in
>    case it is not.

The time display runs from a timer.  Signaling errors from a timer
function is not very useful, and quite annoying.

> 2. custom.el could validate `zoneinfo-style-world-list' when it is set.

How can one do that?  The doc string of world-clock-list says:

  TIMEZONE should be in a format supported by your system.  See the
  documentation of `zoneinfo-style-world-list' and
  `legacy-style-world-list' for two widely used formats.

"Format supported by your system" could be anything defined by Posix
(and potentially non-Posix extensions as well).  According to Posix,
the format of the time-zone definition could be one of these:

     a string of the format "stdoffset[dst[offset][,start[/time],end[/time]]]"
 or:
     the name of a zoneinfo file "Area/Location"
 or:
     :characters (which are "interpreted in implementation-defined manner")

Only the second one can be checked relatively easily by looking in the
directory where the zoneinfo files are installed.  But how does one
validate the other 2 forms?  And how does one know which format iz
used to begin with?

> 3. The docstring of `zoneinfo-style-world-list' and `world-clock' could
>    warn the user about the problem.
> 
> I believe 3 should be implemented in any case.  Ideally it would be
> combined with 1, 2, or preferably both.

We can do 3, sure; done.  The other two "aren't worth the hassle",
IMO.

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

From: Paul Eggert <eggert <at> cs.ucla.edu>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 79437 <at> debbugs.gnu.org, "Jorge P. de Morais Neto" <jorge+git <at> disr.it>
Subject: Re: bug#79437: 30.2; world-clock silently and incorrectly parses
 invalid time zone
Date: Sun, 14 Sep 2025 10:30:37 -0700

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

On 2025-09-13 22:24, Eli Zaretskii wrote:

> Only the second one can be checked relatively easily by looking in the
> directory where the zoneinfo files are installed.  But how does one
> validate the other 2 forms?  And how does one know which format iz
> used to begin with?

Plus, not every TZDB installation has "zoneinfo files" in the usual 
sense; some have a database using some other format.

However, something along those lines could be done, if somebody wanted 
to maintain it (I don't). The idea is not to exactly validate the forms; 
instead, do a reasonably conservative validation that rejects forms that 
(as as we know) are not supported on any Emacs platform. This would 
accept some unlikely mistakes, but would be good enough for most users.

Something like the following, perhaps, and then have world-clock-display 
run (world-clock--check-entries alist) first thing.

None of this is tested; it's just a sketch. And I'm not advocating for 
this change as it's hacky and I would rather not support it, but if 
somebody else wants to take it up it should work acceptably.

  (defconst world-clock--tz-regexp
    (let* ((abbr "\\([A-Za-z]\\{3,\\}\|<[A-Za-z0-9+-]\\{3,\\}>\\)")
           (offset "\\([+-]?[0-9]+\\(:[0-5][0-9]\\(:[0-5][0-9]\\)?\\)?\\)")
           (date "\\(J?[0-9]+\\|M\\([1-9]\\|1[0-2]\\)\\.[1-5]\\.[0-6]\\)")
           (time offset)
           (comma-date-time (concat "," date "\\(/" time "\\)?"))

           ;; TZDB time zones at UTC offset zero at the Epoch.
           ;; The others are filtered out by the call to current-time-zone.
           ;; This list is for circa 2025 TZDB and may need updating.
           (tzdb+0000-regexp
 
"\\(Africa/\\(Abidjan\\|Accra\\|Bamako\\|Banjul\\|Bissau\\|Conakry"
            "" "\\|Dakar\\|Freetown\\|Lome\\|Monrovia\\|Nouakchott"
            "" "\\|Ouagadougou\\|Sao_Tome\\|Timbuktu\\)"
            "\\|America/Danmarkshavn"
            "\\|Atlantic/\\(Azores\\|Reykjavik\\|St_Helena\\)"
            "\\|\\(Etc/\\)?\\(GMT[+-]?0\\|Greenwich\\|UCT\\|UTC"
            "" "\\|Universal\\|Zulu\\)"
            "\\|Iceland")

           ;; POSIX.1-2017 (and earlier) TZ strings.
           (posix-tz-regexp
            (concat "\\(" abbr offset
                    "\\(" abbr offset
                    "?\\(" comma-date-time comma-date-time
                    "\\)?\\)?\\)")))
      (concat "\\`:?\\(" tzdb+0000-regexp
              "\\|" posix-tz-regexp "\\)\\'")))

  (defun world-clock--check-entries (alist)
    (dolist (pair alist)
      (let ((tz (car pair)))
        (unless (string-match-p world-clock--tz-regexp tz)
          (when (zerop (car (current-time-zone 0 tz)))
            (error "Invalid time zone specification" tz))))))

PS. I noticed some other glitches in this area and installed the 
attached patch on master. It's a pain to maintain this stuff!

[0001-Fix-incorrect-timezones-for-London-and-Paris.patch (text/x-patch, attachment)]

Previous Next

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