Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Date: Fri, 14 Aug 2015 11:39:54 -0400
From: Rich Felker <>
Subject: Re: strptime() lacks support for %z

On Fri, Aug 14, 2015 at 05:08:23PM +0200, Szabolcs Nagy wrote:
> > > > strftime uses tzset (timezone from TZ) but strptime cannot
> > > > set TZ so it must put the timezone somewhere else.
> > > > 
> > > > so strptime can't be consistent with strftime.
> > > > with tz in struct tm, mktime/localtime no longer roundtrip.
> > > 
> > > I don't follow. strftime uses the extended fields from struct tm. I
> > > don't see anywhere it depends on tzset, nor reasons why strptime would
> > > need tzset to be called. Am I missing something?
> > > 
> > 
> > it seems %z does not use it in musl, %Z does
> > 
> > __tm_to_tzname calls do_tzset()
> > 
> > posix says
> > "Local timezone information is used as though strftime() called tzset()"
> ah ok, the tz name and offset are independent
> i expected both of those would be used from TZ in
> strftime, but musl already uses the tm struct offset.

Because we support zoneinfo files, printing this information with
strftime does not seem to be possible without using the data from the
struct tm. There can be multiple different offsets and zone names
depending on the date, and strftime does not seem to require a
canonical-form struct tm, so trying to derive the zone/offset in
effect from TZ and the standard struct tm members does not seem like
it could be done reliably. Unfortunately this is all a bit of a mess
because POSIX is in some sort of denial that zoneinfo is necessary...


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.