From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/11891 Path: news.gmane.org!.POSTED!not-for-mail From: Rich Felker Newsgroups: gmane.linux.lib.musl.general Subject: Re: strftime %Z returning empty string Date: Thu, 31 Aug 2017 17:56:53 -0400 Message-ID: <20170831215653.GI1627@brightrain.aerifal.cx> References: <59A87527.3070700@adelielinux.org> Reply-To: musl@lists.openwall.com NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: blaine.gmane.org 1504216630 575 195.159.176.226 (31 Aug 2017 21:57:10 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Thu, 31 Aug 2017 21:57:10 +0000 (UTC) User-Agent: Mutt/1.5.21 (2010-09-15) To: musl@lists.openwall.com Original-X-From: musl-return-11904-gllmg-musl=m.gmane.org@lists.openwall.com Thu Aug 31 23:57:06 2017 Return-path: Envelope-to: gllmg-musl@m.gmane.org Original-Received: from mother.openwall.net ([195.42.179.200]) by blaine.gmane.org with smtp (Exim 4.84_2) (envelope-from ) id 1dnXSP-0008B7-P3 for gllmg-musl@m.gmane.org; Thu, 31 Aug 2017 23:57:01 +0200 Original-Received: (qmail 13427 invoked by uid 550); 31 Aug 2017 21:57:06 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-ID: Original-Received: (qmail 13401 invoked from network); 31 Aug 2017 21:57:05 -0000 Content-Disposition: inline In-Reply-To: Original-Sender: Rich Felker Xref: news.gmane.org gmane.linux.lib.musl.general:11891 Archived-At: On Thu, Aug 31, 2017 at 05:12:23PM -0400, jacob@welshcomputing.com wrote: > On Thu, 31 Aug 2017, A. Wilcox wrote: > > >%Z is a glibc extension. I don't believe musl supports it. > > http://pubs.opengroup.org/onlinepubs/9699919799/functions/strftime.html > > Z Replaced by the timezone name or abbreviation, or by no bytes > if no timezone information exists. [tm_isdst] > > That "if no timezone information exists" is rather useless in my > eyes. Exists where? Later text suggests that the TZ environment > variable is relevant. In order for %Z to reliably be able to print something meaningful, the struct tm must contain the extension field tm_zone reflecting the zone to which it applies. Otherwise, there are at least two sources of ambiguity: there's no indication whether the struct tm contains UTC or local time, and in the latter case, tm_isdst is insufficient to disambiguate a zone name, since the TZ (for zoneinfo style TZ) may contain multiple different historical zones that apply to the territory rather than just a single daylight and single normal zone name. The latter ambiguity could probably be dealt with by trying to interpret the struct tm fields to obtain an absolute time, then determine according to the current TZ what zone name was in effect at that time. But this doesn't disambiguate UTC vs local time. If further consideration of the issue by standards committees (mainly Austin Group) determines that there is some behavior that should be followed to resolve the ambiguity, even if it's not a very nice behavior, I'll see what we can do in musl to conform to the standard. But right now it's underspecified and there's really no way to get meaningful information from a zero-filled struct tm. Rich