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

Previous Next

Package: emacs;

Reported by: "Jorge P. de Morais Neto" <jorge+git <at> disr.it>

Date: Fri, 12 Sep 2025 16:06:03 UTC

Severity: normal

Found in version 30.2

Full log


View this message in rfc822 format

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: 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)?




This bug report was last modified 5 days ago.

Previous Next


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