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
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 sho
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 s
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 h
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
On Wed, Sep 28, 2011 at 11:04:11PM +0200, Andreas Schwab wrote:
> Sandro Santilli writes:
>
> > On Wed, Sep 28, 2011 at 12:19:22AM +0200, Andreas Schwab wrote:
> >> Pádraig Brady writes:
> >>
> >> > $ TZ=Japan+1 date
> >>
> >> This is a well-formed POSIX timezone.
> >
> > Meaning UTC+1 ?
>
>
Sandro Santilli writes:
> On Wed, Sep 28, 2011 at 12:19:22AM +0200, Andreas Schwab wrote:
>> Pádraig Brady 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
>>
>> T
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
On Wed, Sep 28, 2011 at 12:19:22AM +0200, Andreas Schwab wrote:
> Pádraig Brady 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=Jap
On Tue, Sep 27, 2011 at 11:52:22PM +0200, Andreas Schwab wrote:
> Pádraig Brady 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
Pádraig Brady 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, sch...@linux-m68k.org
GPG Key
On 09/27/2011 10:47 PM, Andreas Schwab wrote:
> Pádraig Brady 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 clea
Pádraig Brady 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, sch...@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5
"And now for something c
Pádraig Brady 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
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.
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
>
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="F
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 particul
18 matches
Mail list logo