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

Previous Next

To reply to this bug, email your comments to 9614 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: Sandro Santilli <strk <at> keybit.net>
To: bug-coreutils <at> gnu.org
Subject: date ignoring wrong TZ values
Date: Tue, 27 Sep 2011 16:09:13 +0200

I've been puzzled by date(1) giving weird results
when setting TZ to values unknown by zoneinfo.

As far as:

 $ TZ=Fake date
 Tue Sep 27 14:06:32 Fake 2011

It would be more helpful if the command raised an error 
or warning about "unknown" timezones rather than giving
random dates.

It's particularly anonying when the same TZ _reported_
by the command isn't recognized in input:

  $ date
  Tue Sep 27 16:08:13 CEST 2011

  $ TZ=CEST date
  Tue Sep 27 14:08:13 CEST 2011

Thanks for making a clock available for everyone, btw :)

--strk;

  ()   Free GIS & Flash consultant/developer
  /\   http://strk.keybit.net/services.html

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

From: Pádraig Brady <P <at> draigBrady.com>
To: Sandro Santilli <strk <at> keybit.net>
Cc: 9614 <at> debbugs.gnu.org
Subject: Re: bug#9614: date ignoring wrong TZ values
Date: Tue, 27 Sep 2011 19:19:12 +0100

On 09/27/2011 03:09 PM, Sandro Santilli wrote:
> I've been puzzled by date(1) giving weird results
> when setting TZ to values unknown by zoneinfo.
> 
> As far as:
> 
>  $ TZ=Fake date
>  Tue Sep 27 14:06:32 Fake 2011

Yes, that is per POSIX.
One can specify info about the timezone in TZ
like TZ="Fake+6", so one couldn't start warning about that.

> It would be more helpful if the command raised an error 
> or warning about "unknown" timezones rather than giving
> random dates.
> 
> It's particularly anonying when the same TZ _reported_
> by the command isn't recognized in input:
> 
>   $ date
>   Tue Sep 27 16:08:13 CEST 2011
> 
>   $ TZ=CEST date
>   Tue Sep 27 14:08:13 CEST 2011
> 
> Thanks for making a clock available for everyone, btw :)

Wow you learn something everyday.
I thought the TZ=XYZ was just treated as UTC+0
to allow one to specify TZ=XYZ+4 etc. as
an offset from UTC.

But in fact some TZ values are matched,
as can be seen for CET here on my system:

$ TZ=CEST date
Tue Sep 27 18:03:05 CEST 2011
$ TZ=CET date
Tue Sep 27 20:03:09 CEST 2011
$ date
Tue Sep 27 19:03:17 IST 2011

There are a few three letter codes on my
system at /usr/share/zoneinfo/
(maybe these are the only non ambiguous ones?)

Hmm, how about we warn if an unmatched code (without a /)
is specified, without any other info like UTC offset etc.?

cheers,
Pádraig.

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

From: Sandro Santilli <strk <at> keybit.net>
To: Pádraig Brady <P <at> draigBrady.com>
Cc: 9614 <at> debbugs.gnu.org
Subject: Re: bug#9614: date ignoring wrong TZ values
Date: Tue, 27 Sep 2011 21:37:12 +0200

On Tue, Sep 27, 2011 at 07:19:12PM +0100, Pádraig Brady wrote:
> On 09/27/2011 03:09 PM, Sandro Santilli wrote:
> > I've been puzzled by date(1) giving weird results
> > when setting TZ to values unknown by zoneinfo.
> > 
> > As far as:
> > 
> >  $ TZ=Fake date
> >  Tue Sep 27 14:06:32 Fake 2011
> 
> Yes, that is per POSIX.
> One can specify info about the timezone in TZ
> like TZ="Fake+6", so one couldn't start warning about that.
> 
> > It would be more helpful if the command raised an error 
> > or warning about "unknown" timezones rather than giving
> > random dates.
> > 
> > It's particularly anonying when the same TZ _reported_
> > by the command isn't recognized in input:
> > 
> >   $ date
> >   Tue Sep 27 16:08:13 CEST 2011
> > 
> >   $ TZ=CEST date
> >   Tue Sep 27 14:08:13 CEST 2011
> > 
> > Thanks for making a clock available for everyone, btw :)
> 
> Wow you learn something everyday.
> I thought the TZ=XYZ was just treated as UTC+0
> to allow one to specify TZ=XYZ+4 etc. as
> an offset from UTC.
> 
> But in fact some TZ values are matched,
> as can be seen for CET here on my system:
> 
> $ TZ=CEST date
> Tue Sep 27 18:03:05 CEST 2011
> $ TZ=CET date
> Tue Sep 27 20:03:09 CEST 2011
> $ date
> Tue Sep 27 19:03:17 IST 2011
> 
> There are a few three letter codes on my
> system at /usr/share/zoneinfo/
> (maybe these are the only non ambiguous ones?)
> 
> Hmm, how about we warn if an unmatched code (without a /)
> is specified, without any other info like UTC offset etc.?

Better than nothing, I guess.

--strk;

  ()   Free GIS & Flash consultant/developer
  /\   http://strk.keybit.net/services.html

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

From: Pádraig Brady <P <at> draigBrady.com>
To: Sandro Santilli <strk <at> keybit.net>
Cc: 9614 <at> debbugs.gnu.org
Subject: Re: bug#9614: date ignoring wrong TZ values
Date: Tue, 27 Sep 2011 22:06:20 +0100

On 09/27/2011 07:19 PM, Pádraig Brady wrote:
> On 09/27/2011 03:09 PM, Sandro Santilli wrote:
>> I've been puzzled by date(1) giving weird results
>> when setting TZ to values unknown by zoneinfo.
>>
>> As far as:
>>
>>  $ TZ=Fake date
>>  Tue Sep 27 14:06:32 Fake 2011
> 
> Yes, that is per POSIX.
> One can specify info about the timezone in TZ
> like TZ="Fake+6", so one couldn't start warning about that.
> 
>> It would be more helpful if the command raised an error 
>> or warning about "unknown" timezones rather than giving
>> random dates.
>>
>> It's particularly anonying when the same TZ _reported_
>> by the command isn't recognized in input:
>>
>>   $ date
>>   Tue Sep 27 16:08:13 CEST 2011
>>
>>   $ TZ=CEST date
>>   Tue Sep 27 14:08:13 CEST 2011
>>
>> Thanks for making a clock available for everyone, btw :)
> 
> Wow you learn something everyday.
> I thought the TZ=XYZ was just treated as UTC+0
> to allow one to specify TZ=XYZ+4 etc. as
> an offset from UTC.
> 
> But in fact some TZ values are matched,
> as can be seen for CET here on my system:
> 
> $ TZ=CEST date
> Tue Sep 27 18:03:05 CEST 2011
> $ TZ=CET date
> Tue Sep 27 20:03:09 CEST 2011
> $ date
> Tue Sep 27 19:03:17 IST 2011
> 
> There are a few three letter codes on my
> system at /usr/share/zoneinfo/
> (maybe these are the only non ambiguous ones?)
> 
> Hmm, how about we warn if an unmatched code (without a /)
> is specified, without any other info like UTC offset etc.?

Actually we could warn about unmatched codes containing / too.

I just noticed more inconsistencies, for codes that are matched:

 $ TZ=NZ+1 date # No zone reported
 Tue Sep 27 21:03:06  2011
 $ TZ=CET+1 date # Zone reported
 Tue Sep 27 20:03:16 CET 2011

thanks,
Pádraig.

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

From: Andreas Schwab <schwab <at> linux-m68k.org>
To: Pádraig Brady <P <at> draigBrady.com>
Cc: 9614 <at> debbugs.gnu.org, Sandro Santilli <strk <at> keybit.net>
Subject: Re: bug#9614: date ignoring wrong TZ values
Date: Tue, 27 Sep 2011 23:52:22 +0200

Pádraig Brady <P <at> draigBrady.com> writes:

> On 09/27/2011 03:09 PM, Sandro Santilli wrote:
>> I've been puzzled by date(1) giving weird results
>> when setting TZ to values unknown by zoneinfo.
>> 
>> As far as:
>> 
>>  $ TZ=Fake date
>>  Tue Sep 27 14:06:32 Fake 2011
>
> Yes, that is per POSIX.

This is not a POSIX format, since it lacks the offset.

Andreas.

-- 
Andreas Schwab, schwab <at> linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

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

From: Andreas Schwab <schwab <at> linux-m68k.org>
To: Pádraig Brady <P <at> draigBrady.com>
Cc: 9614 <at> debbugs.gnu.org, Sandro Santilli <strk <at> keybit.net>
Subject: Re: bug#9614: date ignoring wrong TZ values
Date: Tue, 27 Sep 2011 23:47:50 +0200

Pádraig Brady <P <at> draigBrady.com> writes:

>  $ TZ=NZ+1 date # No zone reported

This is undefined.  A zone name in a POSIX time zone must have at least
three letters.

Andreas.

-- 
Andreas Schwab, schwab <at> linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

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

From: Pádraig Brady <P <at> draigBrady.com>
To: Andreas Schwab <schwab <at> linux-m68k.org>
Cc: 9614 <at> debbugs.gnu.org, Sandro Santilli <strk <at> keybit.net>
Subject: Re: bug#9614: date ignoring wrong TZ values
Date: Tue, 27 Sep 2011 23:05:24 +0100

On 09/27/2011 10:47 PM, Andreas Schwab wrote:
> Pádraig Brady <P <at> draigBrady.com> writes:
> 
>>  $ TZ=NZ+1 date # No zone reported
> 
> This is undefined.  A zone name in a POSIX time zone must have at least
> three letters.

I considered that, but it seems inconsequential in this case.
I'd advise people to stay clear of these abbreviations and offsets completely.

$ TZ=GB-Eire+1 date
Tue Sep 27 22:02:49  2011
$ TZ=Japan+1 date
Tue Sep 27 21:02:54 Japan 2011
$ TZ=Japan date
Wed Sep 28 07:03:53 JST 2011

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

From: Andreas Schwab <schwab <at> linux-m68k.org>
To: Pádraig Brady <P <at> draigBrady.com>
Cc: 9614 <at> debbugs.gnu.org, Sandro Santilli <strk <at> keybit.net>
Subject: Re: bug#9614: date ignoring wrong TZ values
Date: Wed, 28 Sep 2011 00:19:22 +0200

Pádraig Brady <P <at> draigBrady.com> writes:

> $ TZ=GB-Eire+1 date

A POSIX timezone name cannot have dashes.

> $ TZ=Japan+1 date

This is a well-formed POSIX timezone.

> $ TZ=Japan date

This is a non-POSIX timezone that happens to match an Olson timezone.

Andreas.

-- 
Andreas Schwab, schwab <at> linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

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

From: Sandro Santilli <strk <at> keybit.net>
To: Andreas Schwab <schwab <at> linux-m68k.org>
Cc: 9614 <at> debbugs.gnu.org, Pádraig Brady <P <at> draigBrady.com>
Subject: Re: bug#9614: date ignoring wrong TZ values
Date: Wed, 28 Sep 2011 07:44:01 +0200

On Wed, Sep 28, 2011 at 12:19:22AM +0200, Andreas Schwab wrote:
> Pádraig Brady <P <at> draigBrady.com> writes:
> 
> > $ TZ=GB-Eire+1 date
> 
> A POSIX timezone name cannot have dashes.

Doesn't all these "can't have" and "undefined" specs mean
we do can warn or error out w/out breakin POSIX compatibility ?

> > $ TZ=Japan+1 date
> 
> This is a well-formed POSIX timezone.

Meaning UTC+1 ?

> > $ TZ=Japan date
> 
> This is a non-POSIX timezone that happens to match an Olson timezone.

non-POSIX means illegal ?

--strk; 

  ()   Free GIS & Flash consultant/developer
  /\   http://strk.keybit.net/services.html

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

From: Sandro Santilli <strk <at> keybit.net>
To: Andreas Schwab <schwab <at> linux-m68k.org>
Cc: 9614 <at> debbugs.gnu.org, Pádraig Brady <P <at> draigBrady.com>
Subject: Re: bug#9614: date ignoring wrong TZ values
Date: Wed, 28 Sep 2011 07:44:51 +0200

On Tue, Sep 27, 2011 at 11:52:22PM +0200, Andreas Schwab wrote:
> Pádraig Brady <P <at> draigBrady.com> writes:
> 
> > On 09/27/2011 03:09 PM, Sandro Santilli wrote:
> >> I've been puzzled by date(1) giving weird results
> >> when setting TZ to values unknown by zoneinfo.
> >> 
> >> As far as:
> >> 
> >>  $ TZ=Fake date
> >>  Tue Sep 27 14:06:32 Fake 2011
> >
> > Yes, that is per POSIX.
> 
> This is not a POSIX format, since it lacks the offset.

A warning/error message with hint on how to correctly form
the string would be very friendly for users.

--strk;

  ()   Free GIS & Flash consultant/developer
  /\   http://strk.keybit.net/services.html

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

From: Paul Eggert <eggert <at> cs.ucla.edu>
To: Sandro Santilli <strk <at> keybit.net>
Cc: 9614 <at> debbugs.gnu.org
Subject: Re: bug#9614: date ignoring wrong TZ values
Date: Tue, 27 Sep 2011 22:48:35 -0700

On 09/27/11 22:44, Sandro Santilli wrote:
> A warning/error message with hint on how to correctly form
> the string would be very friendly for users

Unfortunately, there's no portable way to determine
which TZ values are supported on the current platform.
One cannot even reliably determine whether the current TZ
value is supported.  So it's not clear how that warning
would be generated.

Also, lots of programs use TZ; it's not just "date".

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

From: Andreas Schwab <schwab <at> linux-m68k.org>
To: Sandro Santilli <strk <at> keybit.net>
Cc: 9614 <at> debbugs.gnu.org, Pádraig Brady <P <at> draigBrady.com>
Subject: Re: bug#9614: date ignoring wrong TZ values
Date: Wed, 28 Sep 2011 23:04:11 +0200

Sandro Santilli <strk <at> keybit.net> writes:

> On Wed, Sep 28, 2011 at 12:19:22AM +0200, Andreas Schwab wrote:
>> Pádraig Brady <P <at> draigBrady.com> writes:
>> 
>> > $ TZ=Japan+1 date
>> 
>> This is a well-formed POSIX timezone.
>
> Meaning UTC+1 ?

The timzone name has no meaning, only the offset matters.

>> > $ TZ=Japan date
>> 
>> This is a non-POSIX timezone that happens to match an Olson timezone.
>
> non-POSIX means illegal ?

It means unspecified (but not undefined), ie. the implementation may
reject it or do something sensible.

Andreas.

-- 
Andreas Schwab, schwab <at> linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

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

From: Sandro Santilli <strk <at> keybit.net>
To: Andreas Schwab <schwab <at> linux-m68k.org>
Cc: 9614 <at> debbugs.gnu.org, Pádraig Brady <P <at> draigBrady.com>
Subject: Re: bug#9614: date ignoring wrong TZ values
Date: Thu, 29 Sep 2011 10:38:58 +0200

On Wed, Sep 28, 2011 at 11:04:11PM +0200, Andreas Schwab wrote:
> Sandro Santilli <strk <at> keybit.net> writes:
> 
> > On Wed, Sep 28, 2011 at 12:19:22AM +0200, Andreas Schwab wrote:
> >> Pádraig Brady <P <at> draigBrady.com> writes:
> >> 
> >> > $ TZ=Japan+1 date
> >> 
> >> This is a well-formed POSIX timezone.
> >
> > Meaning UTC+1 ?
> 
> The timzone name has no meaning, only the offset matters.

Offset from which date ?

> >> > $ TZ=Japan date
> >> 
> >> This is a non-POSIX timezone that happens to match an Olson timezone.
> >
> > non-POSIX means illegal ?
> 
> It means unspecified (but not undefined), ie. the implementation may
> reject it or do something sensible.

So it can also print a warning ?

--strk; 

  ()   Free GIS & Flash consultant/developer
  /\   http://strk.keybit.net/services.html

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

From: Assaf Gordon <assafgordon <at> gmail.com>
To: Paul Eggert <eggert <at> cs.ucla.edu>, Sandro Santilli <strk <at> keybit.net>
Cc: 9614 <at> debbugs.gnu.org
Subject: Re: bug#9614: date ignoring wrong TZ values
Date: Mon, 15 Oct 2018 08:11:44 -0600

tags 9614 wontfix
severity 9614 wishlist
retitle 9614 date: warn on invalid TZ string (was: date ignoring wrong 
TZ values)
stop

(triaging old bugs)

Hello,

On 27/09/11 11:48 PM, Paul Eggert wrote:
> On 09/27/11 22:44, Sandro Santilli wrote:
>> A warning/error message with hint on how to correctly form
>> the string would be very friendly for users
> 
> Unfortunately, there's no portable way to determine
> which TZ values are supported on the current platform.
> One cannot even reliably determine whether the current TZ
> value is supported.  So it's not clear how that warning
> would be generated.
> 
> Also, lots of programs use TZ; it's not just "date".
> 

Based on the above, and no follow-ups in 7 years,
I'm closing this bug. Discussion can continue by replying to this thread.

-assaf

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

From: Assaf Gordon <assafgordon <at> gmail.com>
To: Paul Eggert <eggert <at> cs.ucla.edu>, Sandro Santilli <strk <at> keybit.net>
Cc: 9614 <at> debbugs.gnu.org
Subject: Re: bug#9614: date ignoring wrong TZ values
Date: Mon, 31 Dec 2018 10:03:58 -0700

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

Hello,

On 2018-10-15 8:11 a.m., Assaf Gordon wrote:
> tags 9614 wontfix
> severity 9614 wishlist

Changed my mind (and noticed that Paul removed the "wontfix" tag),
so here goes...


> On 27/09/11 11:48 PM, Paul Eggert wrote:
>> On 09/27/11 22:44, Sandro Santilli wrote:
>>> A warning/error message with hint on how to correctly form
>>> the string would be very friendly for users
>>
>> Unfortunately, there's no portable way to determine
>> which TZ values are supported on the current platform.
>> One cannot even reliably determine whether the current TZ
>> value is supported.  So it's not clear how that warning
>> would be generated.
>>

Attached is a crude attempt at detecting and warning about invalid
timezone strings.

First and foremost,
the code only runs when the user specify "--debug", so hopefully it
won't have any ill effects.

Second,
the goal is to detect the most common usage errors (e.g.
"America/NewYorx" or "Jamaika"), not to re-implement a fool-proof parser
for timezones.

Third,
The code runs "mostly well" on "most common" operating systems.
There sure to be cases where it doesn't work (but the "doesn't work"
part simply means that with "--debug" it might warn about invalid
timezone when it is a valid timezone that resolves to GMT).
OpenBSD is such a case.

---

With this patch, "date --debug" is able to warn about:

   TZ=America/NewYorx date --debug
   TZ=Europe/Lomdom date --debug
   TZ=FOOBAR date --debug
   date --debug -d 'TZ="Asia/Japan" 2019-01-01'

while it knows not to warn about:

   TZ=Africa/Dakar date --debug   # Valid GMT timezone
   TZ=GB date --debug             # Valid GMT timezone on most systems
   TZ=FOO+0 date --debug          # Valid UTC+0 timezone

The warning looks like so:

   $ TZ=America/Kalgary ./src/date --debug
   date: possibly invalid timezone in TZ envvar:
   date:    ‘America/Kalgary’
   date: timezone UTC0 will be used.
   Mon Dec 31 16:41:08 America 2018

The detection works well on Debian 9, Centos 7,
FreeBSD 11, NetBSD 7.1, AIX 7.2 .

OpenBSD is an example of where it doesn't work - there's no way
to differentiate between an invalid timezone and a valid GMT timezone.
But on such system, the code self-diagnoses this issue and prints
additional warnings:

  $ TZ=Africa/Dakar ./src/date --debug
  date: possibly invalid timezone in TZ envvar:
  date:    'Africa/Dakar'
  date: timezone UTC0 will be used.
  date: this system has limited capabilities in detecting
  date: invalid timezones. It is possible this is a valid timezone
  date: in the GMT zone.
  Mon Dec 31 16:43:35 GMT 2018

---

This patch includes a unit-test, but because the names of available
timezones vary so much between systems, it doesn't pass everywhere.
It is therefore marked as "very expensive".

To run it, use:

    make check SUBDIRS=. TESTS=tests/misc/date-debug-TZ.pl \
               RUN_VERY_EXPENSIVE_TESTS=yes

---

The heuristic code to determine if a timezone is valid or not is quite
hairy. There's likely room for improvements.


Comments and feedback and improvement suggestions are welcomed,
 - assaf

[0001-date-detect-and-warn-about-invalid-TZ-values-with-de.patch.gz (application/gzip, attachment)]

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

From: Paul Eggert <eggert <at> cs.ucla.edu>
To: Assaf Gordon <assafgordon <at> gmail.com>, Sandro Santilli <strk <at> keybit.net>
Cc: 9614 <at> debbugs.gnu.org
Subject: Re: bug#9614: date ignoring wrong TZ values
Date: Tue, 1 Jan 2019 23:08:26 -0800

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.

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

From: Assaf Gordon <assafgordon <at> gmail.com>
To: Paul Eggert <eggert <at> cs.ucla.edu>
Cc: 9614 <at> debbugs.gnu.org
Subject: Re: 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

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

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

Assaf Gordon wrote:

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

That's what I was thinking of, except that it'd be better to extend glibc to 
support tzalloc etc. That code could be shared between glibc and gnulib.

Previous Next

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