GNU bug report logs - #9614
date: warn on invalid TZ string (was: date ignoring wrong

Previous Next

Full log

View this message in rfc822 format

From: Assaf Gordon <assafgordon <at> gmail.com>
To: Paul Eggert <eggert <at> cs.ucla.edu>
Cc: 9614 <at> debbugs.gnu.org
Subject: bug#9614: date ignoring wrong TZ values
Date: Wed, 2 Jan 2019 00:52:48 -0700

Hello Paul,

On 2019-01-02 12:08 a.m., Paul Eggert wrote:
> I think this implementation is heading in the wrong direction. To 
> determine whether a time zone string FOO is valid, a program should call 
> tzalloc (FOO) and sees whether that yields NULL.  And if tzalloc doesn't 
> work that way now, we should fix tzalloc so it does. Once that happens, 
> 'date' can simply call tzalloc (getenv ("TZ")) to see whether the time 
> zone setting is OK.

Thanks for the feedback.

Asking for a bit more details, clarifications...

If I understand correctly, the current gnulib implementation
of "tzalloc" is very minimal and without any checks.
Basically the only way for it to return NULL is if the malloc failed.
https://git.sv.gnu.org/cgit/gnulib.git/tree/lib/time_rz.c#n92

And previously you wrote:
> Unfortunately, there's no portable way to determine
> which TZ values are supported on the current platform.

So do you mean that:

This sort of heuristics (or another/better heuristic implementation)
should be moved into gnulib, and 'hidden' with tzalloc's very simple 
interface?
(date already calls tzalloc(getenv("TZ")) but doesn't check the returned 
value.)

or

gnulib's tzalloc implementation should be greatly expanded to be able
to decode the operating system's local timezome?
(or perhaps the timezone management code copied from glibc?)

or

something completely different?

thanks!
 - assaf

Previous Next

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