strftime %Z returning empty string

strftime %Z returning empty string

[jacob]

Hello,

I've been working through the Python test suite (2.7.13) on musl (1.1.16). 
There were a couple over-zealous tests involving errno, and locale tests 
that I'd expect to fail, but one set of failures I haven't yet been able 
to rule out as a musl bug. Symptom:

     >>> time.strftime('%Z')
     'GMT'
     >>> time.strftime('%Z', time.localtime())
     ''

The Python docs say these should be equivalent.

The implementation is about what you'd expect: if the second argument to 
time.strftime() is omitted, it passes the results of C localtime() 
directly to strftime(); otherwise it builds a "struct tm" by "memset"ing 
to '\0' then assigning the public fields (which of course don't include a 
time zone).

Bug? Bad assumption on their part? Nonsensical standard?

Thanks,
J. Welsh

Re: strftime %Z returning empty string

[A. Wilcox]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On 31/08/17 15:23, jacob@welshcomputing.com wrote:
> Hello,
> 
> I've been working through the Python test suite (2.7.13) on musl 
> (1.1.16). There were a couple over-zealous tests involving errno,
> and locale tests that I'd expect to fail, but one set of failures I
> haven't yet been able to rule out as a musl bug. Symptom:
> 
>>>> time.strftime('%Z')
> 'GMT'
>>>> time.strftime('%Z', time.localtime())
> ''
> 
> The Python docs say these should be equivalent.
> 
> The implementation is about what you'd expect: if the second
> argument to time.strftime() is omitted, it passes the results of C
> localtime() directly to strftime(); otherwise it builds a "struct
> tm" by "memset"ing to '\0' then assigning the public fields (which
> of course don't include a time zone).
> 
> Bug? Bad assumption on their part? Nonsensical standard?
> 
> Thanks, J. Welsh


%Z is a glibc extension.  I don't believe musl supports it.

Best,
- --arw

- -- 
A. Wilcox (awilfox)
Project Lead, Adélie Linux
http://adelielinux.org
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQIcBAEBCAAGBQJZqHUJAAoJEMspy1GSK50U6ksP/RPMfan6rKijFRS/6u5TDtam
MnX6h9qCKvG5biaxH8vrb6qFP5bi/4IDHUM/dFsVHalCPmXrXYE6l/hb4nUmLCo0
ysbQ5vXilvY9gHHKxatOnHl0BH3YCxQoMGfJl1qcwfhH3ELfq5waVYNBN+lMueKV
/qrtEIFcX1dWMnXnlyYuVoPL50Vt2qocKJ5i8U0fRNj96q2/foR4THAyQlgvWU2b
oBZSNIr8bfrKjueNVA+0fzbPwmRj4nZaMHrmRXSgYpzEwuWkJNTstK12cksB8xp/
gmC8g3L1M/3Hj8YyJRbTRvF3ppgDZ7Glay+5n9ei0ZRKGJLOMY/k56wfWRApdAxC
j9I39V52cgPheuVqvbTUGFrC9+vGptxT8zZRYEEXQmbKDw5z96QHbYebXtKuR3SV
dcIREhOgyyS0TRCPDr1JB+giOxAADKTcZCFEeTn6A0o/ng06ccCEt0oztBVcB629
BVpq9QxfCKL2OBtXx1v0qB0GZDFGeKMK+fShBO/m/k7DvOL35rXKded5Wl9zk2fK
O3HEBTvbrGnuQOQuEAMQpsdEnCfsEaNe+WOYveb/x33Q/dB+Jcy1/INte38levqS
63YCvTp7CyNGdG3Alr0bJk36srH2DR45JioJlWuwRI/MccGDUny5VHcZf5VEWUUU
XsO/fQqzLwKnEkAT1rc5
=h9Bi
-----END PGP SIGNATURE-----

Re: strftime %Z returning empty string

[jacob]

On Thu, 31 Aug 2017, A. Wilcox wrote:

> %Z is a glibc extension.  I don't believe musl supports it.

http://pubs.opengroup.org/onlinepubs/9699919799/functions/strftime.html

     Z       Replaced by the timezone name or abbreviation, or by no bytes
             if no timezone information exists. [tm_isdst]

That "if no timezone information exists" is rather useless in my eyes. 
Exists where? Later text suggests that the TZ environment variable is 
relevant.

J. Welsh

Re: strftime %Z returning empty string

[Rich Felker]

On Thu, Aug 31, 2017 at 05:12:23PM -0400, jacob@welshcomputing.com wrote:
> On Thu, 31 Aug 2017, A. Wilcox wrote:
> 
> >%Z is a glibc extension.  I don't believe musl supports it.
> 
> http://pubs.opengroup.org/onlinepubs/9699919799/functions/strftime.html
> 
>     Z       Replaced by the timezone name or abbreviation, or by no bytes
>             if no timezone information exists. [tm_isdst]
> 
> That "if no timezone information exists" is rather useless in my
> eyes. Exists where? Later text suggests that the TZ environment
> variable is relevant.

In order for %Z to reliably be able to print something meaningful, the
struct tm must contain the extension field tm_zone reflecting the zone
to which it applies. Otherwise, there are at least two sources of
ambiguity: there's no indication whether the struct tm contains UTC or
local time, and in the latter case, tm_isdst is insufficient to
disambiguate a zone name, since the TZ (for zoneinfo style TZ) may
contain multiple different historical zones that apply to the
territory rather than just a single daylight and single normal zone
name.

The latter ambiguity could probably be dealt with by trying to
interpret the struct tm fields to obtain an absolute time, then
determine according to the current TZ what zone name was in effect at
that time. But this doesn't disambiguate UTC vs local time.

If further consideration of the issue by standards committees (mainly
Austin Group) determines that there is some behavior that should be
followed to resolve the ambiguity, even if it's not a very nice
behavior, I'll see what we can do in musl to conform to the standard.
But right now it's underspecified and there's really no way to get
meaningful information from a zero-filled struct tm.

Rich

Re: strftime %Z returning empty string

[Szabolcs Nagy]

* A. Wilcox <awilfox@adelielinux.org> [2017-08-31 15:44:23 -0500]:
> 
> %Z is a glibc extension.  I don't believe musl supports it.
> 

it's an extension in strptime and also implmented by
bsd systems (though a bit differently than in glibc),
but specified for strftime.

musl's asctime catches Python bug

[jacob]

> I've been working through the Python test suite (2.7.13) on musl (1.1.16). 
> There were a couple over-zealous tests involving errno, and locale tests that 
> I'd expect to fail, but one set of failures I haven't yet been able to rule 
> out as a musl bug.

There was another bug that I didn't want to mention until Python security 
had a chance to respond: undefined behavior in their asctime()/ctime() 
wrappers for year > 9999, found by virtue of musl's use of a_crash to 
highlight the problem.

The public discussion is at https://bugs.python.org/issue31339 if anyone's 
interested.

Cheers,
J. Welsh

Re: musl's asctime catches Python bug

[Rich Felker]

On Mon, Sep 04, 2017 at 07:27:08PM -0400, jacob@welshcomputing.com wrote:
> >I've been working through the Python test suite (2.7.13) on musl
> >(1.1.16). There were a couple over-zealous tests involving errno,
> >and locale tests that I'd expect to fail, but one set of failures
> >I haven't yet been able to rule out as a musl bug.
> 
> There was another bug that I didn't want to mention until Python
> security had a chance to respond: undefined behavior in their
> asctime()/ctime() wrappers for year > 9999, found by virtue of
> musl's use of a_crash to highlight the problem.
> 
> The public discussion is at https://bugs.python.org/issue31339 if
> anyone's interested.

I didn't see a direct link to the fix anywhere, but it's pretty clear
that the right thing to do is call strftime (a clean interface that
lacks global state and thread-safety problems) and/or strftime_l and
never use ctime/asctime.

Rich