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 31661 invoked from network); 12 Aug 2020 14:13:17 -0000 Received: from mother.openwall.net (195.42.179.200) by inbox.vuxu.org with ESMTPUTF8; 12 Aug 2020 14:13:17 -0000 Received: (qmail 30024 invoked by uid 550); 12 Aug 2020 14:13:12 -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 26092 invoked from network); 12 Aug 2020 14:05:46 -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=3aALkL0q7zSj3INmKNh22vzBFaZtBZCP+Ugz+ilpfhI=; b=W2K9BqUz9nfoT7cr6bUrq4FxwMcZOzMA/ZgniFVAs3yyz8jF/TYO9/yqw8+gJ2Acbf f5J7NGs9KAr6ZpD/V7oV25yAEd3ZchqJYB40mrYBmVWCAET519WWhgsInAADdGgWURu2 7sSNBL4lPu03nJK06bG9VNKbVWyxqM+v7Df3DN5dKAWAi9AQ991OxSOy9ExMDxcqLw2F 44bFYOcpm1M04rVv5WeY1l+yVx2/NZ71MC7KdHQ4E45prmVFm7F3J2KLxkWZMoFWYtZW +Yc77EuFGenFqyCg/Z1Ys+zhnbknpsQngnKdxMgu3qMn7jG1SQfaYYugpvi9mCpwur56 QzRw== 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=3aALkL0q7zSj3INmKNh22vzBFaZtBZCP+Ugz+ilpfhI=; b=DVhwsnsZUravKrj5eSLbvDh2X91E2ZwwBgdt0arOW5tAZce9WWCd6pB5BfF1iVon8H 1/e+28n4Ghr4o0XN2CVR3EPrwn8zvc4H4yX3oFqZHfg2Pk3BbR+eQla6LERnlv5cwYif CtotB3j7WYMGqmlHf0+F2OJsweclmfTyOqdqoehNpDAyv6oG5SsWwCrmLra4UbcXxwlp fHoWqsINSKvL4vVRc8xTv0HmqTLTRb0k0IjDXR29bMlFr844QZO/3gegBinV5F0DD41c +Vu5/FNctVFb5JZHRDvm7fumA/f9PgFs9FG0f1y5b13qrkfPtanKgdoPYv8DKMBN050s U/cQ== X-Gm-Message-State: AOAM533HygHBJOXpkWpA9ytvkCKYHQ7J4DrFOg8/GaAwZIaMDvLLggxw 3d7DHT8uy7CRxzrWxQYX+qcgy3a3fHGqNcItGlMKbpE3zsJAWQ== X-Google-Smtp-Source: ABdhPJxIbRfAL1wu3/PVbPJ2H9k09PBx2LB2tgZaSp8HEG2LNRpsnMF8/IuPun5TJEASsWBL4C6wqq2D5z6YH2c9XU0= X-Received: by 2002:a2e:a58b:: with SMTP id m11mr5405795ljp.135.1597241134560; Wed, 12 Aug 2020 07:05:34 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Nikita Popov Date: Wed, 12 Aug 2020 16:05:18 +0200 Message-ID: To: musl@lists.openwall.com Content-Type: multipart/alternative; boundary="000000000000723bad05acaeae6d" Subject: [musl] Re: strftime %Z behavior with manually populated struct tm --000000000000723bad05acaeae6d Content-Type: text/plain; charset="UTF-8" On Wed, Aug 12, 2020 at 2:57 PM Nikita Popov wrote: > > 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. > Nevermind, I just confused myself further here. glibc does use tm_zone, with the following comment: /* The POSIX test suite assumes that setting the environment variable TZ to a new value before calling strftime() will influence the result (the %Z format) even if the information in TP is computed with a totally different time zone. This is bogus: though POSIX allows bad behavior like this, POSIX does not require it. Do the right thing instead. */ zone = (const char *) tp->tm_zone; Regards, Nikita --000000000000723bad05acaeae6d Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Wed, Aug 12, 2020 at 2:57 PM Nikita Popov <nikita.ppv@gmail.com> wrote:
> I haven't checked, b= ut I believe most implementations just print the
> zone name from the= current timezone, using tm_isdst to decide whether
> to print the st= andard or daylight version of the name. This is
> insufficient with z= oneinfo for zones where the name changed over time,
> where it would = print the wrong name for historical times. So instead
> we support pr= inting any one of the zone names from the current zone,
> if the= tm_zone member points to one of them, and blank otherwise.

<= /div>
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 d= irection here.=C2=A0

Nevermind,= I just confused myself further here. glibc does use tm_zone, with the foll= owing comment:

=C2=A0=C2=A0=C2=A0 /* The POSIX test sui= te assumes that setting
=C2=A0=C2=A0=C2=A0 the environment variable TZ t= o a new value before calling strftime()
=C2=A0=C2=A0=C2=A0 will influenc= e the result (the %Z format) even if the information in
=C2=A0=C2=A0=C2= =A0 TP is computed with a totally different time zone.
=C2=A0=C2=A0=C2= =A0 This is bogus: though POSIX allows bad behavior like this,
=C2=A0=C2= =A0=C2=A0 POSIX does not require it. Do the right thing instead. */
=C2= =A0=C2=A0=C2=A0 zone =3D (const char *) tp->tm_zone;

Regards,
Nikita
--000000000000723bad05acaeae6d--