Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Wed, 12 Aug 2020 16:05:18 +0200
From: Nikita Popov <>
Subject: Re: strftime %Z behavior with manually populated struct tm

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;


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.