Subject: bug#9614: date ignoring wrong TZ values

From: Assaf Gordon <[email-masked]>
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