Date:Fri, 14 Jun 2024 13:34:28 +1200
From:Martin D Kealey
Message-ID:
| To be clear, this isn't a bug report, but rather a feature request to
| implement a common extension, and to interpret TZ=...,M*m.w* printf in line
| with the rest of GNU.
To that you'd w
On Fri, 14 Jun 2024 at 10:52, Robert Elz wrote:
> | I also note a minor bug/issue with printf in Bash 5.3-alpha: the
> builtin
> | printf treats TZ=CET-1CEST,M3.5,M10.5/3 as if it were oddly-named UTC.
>
> That's user error, POSIX format requires 3 values after the M:
"User error" is not th
Date:Fri, 14 Jun 2024 00:31:31 +1200
From:Martin D Kealey
Message-ID:
| I also note a minor bug/issue with printf in Bash 5.3-alpha: the builtin
| printf treats TZ=CET-1CEST,M3.5,M10.5/3 as if it were oddly-named UTC.
That's user error, POSIX format requires 3
On 6/13/24 8:31 AM, Martin D Kealey wrote:
On Tue, 11 Jun 2024 at 21:52, Grisha Levit wrote:
POSIX says about the TZ variable:
If the dst field is specified and the rule field is not, it is
implementation-defined when the changes to and from DST occur.
musl seems to interpret `TZ=E
On 6/11/24 5:52 AM, Grisha Levit wrote:
POSIX says about the TZ variable:
If the dst field is specified and the rule field is not, it is
implementation-defined when the changes to and from DST occur.
musl seems to interpret `TZ=EST5EDT` as having DST always in effect,
causing the test
On Tue, 11 Jun 2024 at 21:52, Grisha Levit wrote:
> POSIX says about the TZ variable:
>
> If the dst field is specified and the rule field is not, it is
> implementation-defined when the changes to and from DST occur.
>
> musl seems to interpret `TZ=EST5EDT` as having DST always in effect
POSIX says about the TZ variable:
If the dst field is specified and the rule field is not, it is
implementation-defined when the changes to and from DST occur.
musl seems to interpret `TZ=EST5EDT` as having DST always in effect,
causing the tests that rely on the glibc behavior (of defaul
