From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=-3.1 required=5.0 tests=DKIM_ADSP_CUSTOM_MED, DKIM_INVALID,DKIM_SIGNED,FREEMAIL_FROM,HTML_MESSAGE,MAILING_LIST_MULTI, RCVD_IN_DNSWL_MED,RCVD_IN_MSPIKE_H3,RCVD_IN_MSPIKE_WL autolearn=ham autolearn_force=no version=3.4.4 Received: (qmail 25355 invoked from network); 12 Aug 2020 13:15:37 -0000 Received: from mother.openwall.net (195.42.179.200) by inbox.vuxu.org with ESMTPUTF8; 12 Aug 2020 13:15:37 -0000 Received: (qmail 8004 invoked by uid 550); 12 Aug 2020 13:15:33 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-ID: Reply-To: musl@lists.openwall.com Received: (qmail 20355 invoked from network); 12 Aug 2020 12:57:36 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=zRH1khyNhFyGaGyotzVdS7Ep5lDDgqhdf5sQzk7Cvb8=; b=qm+TfRhpyCyf83rnyZHSYSWsVh2qhDJSQlJ1JPH834AV3lfUM7LrkJfsFQMQ9gnkp5 HE5lvded6NprTzPGLLZeUTjJMFnhmb4pApKCw4dEcG0H2HR8kK6IeYWZ+GkEMxyAC/vY 6MBu5Nj4/cQ0EVEf4eTzz07qoSFW7d9JkYbaCrLxhy5iNuo3u3apfYyA+sisRncy0Qyo v8xixT5BWQsEkKcAM8TWjMpkNZz7ukBKYJ4VQK9xLdq17EzGgqPcAdvujupNScr6zHtg E3Xo9DhibQmoc172iBtNFD8J//Pv6QTpqmKbFVyeyOs1kUZPZAJ4k9I/piGQ+ntTklFx AQvQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=zRH1khyNhFyGaGyotzVdS7Ep5lDDgqhdf5sQzk7Cvb8=; b=i0s8A1H0aRl6asjI4ndqxoqtKZgGHa4kGpAjH8s9/60ngNaykoFQziBIflOrPL9MNa JZiMG7mnJfDgtj2mArZNy3a3/G6pNrUC1QAM1K4na8bUPvZyZOKYYIzRSpD1kEc7JCBb LT+63Rdume3sAF1hPVu+8kavCjMLyqDNtZHonXurkSPnw0Azn/+GmI5cX/qr3dE50RbX yS/kuljtyMYkGTqL97tTdxGXT1l+UVB615zgelr/JWX8QcpOBVmXJdoektG3CXXSvfjB ODqkVW837hyyrTIAjrQWv/mC+VeA7hEbSG8oxo1JpqNoi3IGLaRES8iPoCDRXzcuR2f9 XoCw== X-Gm-Message-State: AOAM530ph++Jirs7sD2AUgleLL3pUF+krG8WeJo5pyeeNZ/BGqWPJWey WO3WdT3dXuUo3wVuJ5EIdIUIju2NgBUPMomUlF3K5mdcJGVK4A== X-Google-Smtp-Source: ABdhPJzz7XuNwQ/QNaXE8vC9Q74GGn5NaicIX2ZNOtBoemioYpaPSIdt8R1gLdQkwUlEDdXZtjqA9iD2JxUmMB72Kac= X-Received: by 2002:a2e:a58b:: with SMTP id m11mr5267181ljp.135.1597237044548; Wed, 12 Aug 2020 05:57:24 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Nikita Popov Date: Wed, 12 Aug 2020 14:57:08 +0200 Message-ID: To: musl@lists.openwall.com Content-Type: multipart/alternative; boundary="000000000000a996f505acadba27" Subject: [musl] Re: strftime %Z behavior with manually populated struct tm --000000000000a996f505acadba27 Content-Type: text/plain; charset="UTF-8" > I haven't checked, but I believe most implementations just print the > zone name from the current timezone, using tm_isdst to decide whether > to print the standard or daylight version of the name. This is > insufficient with zoneinfo for zones where the name changed over time, > where it would print the wrong name for historical times. So instead > we support printing any one of the zone names from the current zone, > if the tm_zone member points to one of them, and blank otherwise. You are right. I was under the impression that glibc uses tm_zone, but double checking the implementation right now, it doesn't. So the behavioral discrepancy here comes from the fact that musl checks tm_zone at all, not the other way around. Sorry for looking in the completely wrong direction here. > I think you have the wrong commit link; that one does not look > related. If you have the real one I'd be interested in seeing what > they did. Indeed, I meant to link to https://github.com/python/cpython/commit/5633c4f342d957df2ef0d67b9bfb472a0d28a76b. What Python does is to retrieve musl's string for UTC using gmtime_r, as well as trying to match against the current tzname. > I think if applications want to use zones other than the actual > configured zone with strftime, they need to just do something like > expand the %Z themselves with the string they want before calling > strftime (note: this requires quoting any % in the name). With your explanation in mind, explicitly expanding %Z does seem like a good approach. I'll consider doing that. > I looked > hard for a better solution that wouldn't crash valid applications, and > couldn't find one at the time. Possibly it would make sense to fall back to using the current tzname if the pointer given in tm_zone is invalid, rather than an empty string? Regards, Nikita --000000000000a996f505acadba27 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
> I haven't checked, but I believe most implementat= ions just print the
> zone name from the current timezone, using tm_i= sdst to decide whether
> to print the standard or daylight version of= the name. This is
> insufficient with zoneinfo for zones where the n= ame changed over time,
> where it would print the wrong name for hist= orical times. So instead
> we support printing any one of the zone na= mes from the current zone,
> if the tm_zone member points to one= of them, and blank otherwise.

You are right. I wa= s under the impression that glibc uses tm_zone, but double checking the imp= lementation right now, it doesn't. So the behavioral discrepancy here c= omes from the fact that musl checks tm_zone at all, not the other way aroun= d. Sorry for looking in the completely wrong direction here.
=
> I think you have the wrong commit link; that one does not lo= ok
> related. If you have the real one I'd be interested in seein= g what
> they did.

Indeed, I meant to link to https://github.com/python/cpython/commit/5633c4f342d957df2ef0d67b9b= fb472a0d28a76b. What Python does is to retrieve musl's string for U= TC using gmtime_r, as well as trying to match against the current tzname.
> I think if applications want to use zones other than the actua= l
> configured zone with strftime, they need to just do something lik= e
> expand the %Z themselves with the string they want before calling=
> strftime (note: this requires quoting any % in the name).
With your explanation in mind, explicitly expanding %Z does= seem like a good approach. I'll consider doing that.
<= br>
> I looked
> hard for a better solution that would= n't crash valid applications, and
> couldn't find one at= the time.

Possibly it would make sense to fall ba= ck to using the current tzname if the pointer given in tm_zone is invalid, = rather than an empty string?

Regards,
Ni= kita
--000000000000a996f505acadba27--