[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Wed, 12 Aug 2020 16:05:18 +0200
From: Nikita Popov <nikita.ppv@...il.com>
To: musl@...ts.openwall.com
Subject: Re: strftime %Z behavior with manually populated struct tm
On Wed, Aug 12, 2020 at 2:57 PM Nikita Popov <nikita.ppv@...il.com> 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
Content of type "text/html" skipped
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
