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.3 required=5.0 tests=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 6283 invoked from network); 12 Aug 2020 15:18:05 -0000 Received: from mother.openwall.net (195.42.179.200) by inbox.vuxu.org with ESMTPUTF8; 12 Aug 2020 15:18:05 -0000 Received: (qmail 30334 invoked by uid 550); 12 Aug 2020 15:18:00 -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 30310 invoked from network); 12 Aug 2020 15:17:59 -0000 Date: Wed, 12 Aug 2020 11:17:47 -0400 From: Rich Felker To: musl@lists.openwall.com Message-ID: <20200812151747.GN3265@brightrain.aerifal.cx> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [musl] Re: strftime %Z behavior with manually populated struct tm On Wed, Aug 12, 2020 at 02:57:08PM +0200, 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. > > > 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? This might make sense. I was thinking from a standpoint of most reasonable behavior for an uninitialized field, but but can always give junk anyway (if you happen to have the exact wrong pointer value that points to the current timezone's string area) so it's really not useful to care about that case except for it not crashing. Using tm_isdst and __timezone if the caller zeros the field would still be useful potentially. Rich