[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <14347187-f152-4337-bb1d-4d8c4cce495f@iki.fi>
Date: Wed, 1 Apr 2026 18:48:27 +0300
From: Hannu Nyman <hannu.nyman@....fi>
To: musl@...ts.openwall.com
Subject: Re: strptime in 1.2.6 - is tzname[0/1] guaranteed to be set?
Rich Felker kirjoitti 30.3.2026 klo 23.00:
> On Mon, Mar 30, 2026 at 03:44:12PM -0400, Rich Felker wrote:
>> On Mon, Mar 30, 2026 at 10:34:07PM +0300, Hannu Nyman wrote:
>>> Rich Felker kirjoitti 30.3.2026 klo 22.27:
>>>> Oh, it's a signedness error. Changing it to
>>>>
>>>> while ((**s|32)-'a' < 26U) ++*s;
>>>>
>>>> would fix it. But isalpha might be a nicer approach, yes, especially
>>>> since we have the macro that does exactly that anyway.
>>> After further thought, "isalpha" might actually be wrong, as the quoted
>>> POSIX timezone format like <-02>2 are also valid.
>>>
>>> (Reference to our discussion in 2016 ;-)
>>> https://www.openwall.com/lists/musl/2016/03/31/9
>>>
>>> http://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap08.html#tag_08_03
>>>
>>> In the quoted form, the first character shall be the <less-than-sign> ( '<'
>>> ) character and the last character shall be the <greater-than-sign> ( '>' )
>>> character. All characters between these quoting characters shall be
>>> alphanumeric characters from the portable character set in the current
>>> locale, the <plus-sign> ( '+' ) character, or the <hyphen-minus> ( '-' )
>>> character. The /std/ and /dst/ fields in this case shall not include the
>>> quoting characters.
>>>
>>> Then the STD string might be "-02" and DST would be empty. So, isalpha
>>> would wrongly fail on "-02" which could quite legitimately exist there.
>> POSIX doesn't specify what %Z does in the case where the input does
>> not match either of the tzname strings for the locale. Those quoting
>> forms are for the TZ variable, and the quote marks <> are not
>> considered part of the name, so they would not have been emitted by
>> strftime %Z. Thus, I don't think there's any motivation to match them
>> here. In theory maybe we should consume [A-Za-z0-9+-] that could have
>> been expanded from a quoted TZ name; I'm not sure. But I don't think
>> it matters a lot since this case is not specified. It's really a
>> program error to be passing a string to strptime where the %Z field is
>> not known to have been produced in a way strptime is well-defined to
>> consume.
> Fixed version attached.
>
> Rich
Thanks Rick,
the fix works ok.
Personally I still feel that matching for [A-Za-z0-9+-] would be more
complete in the long run, as most of the new/modified timezones since 2016
have been just numbers (in the quoted format), so that a quite big portion of
timezone abbreviations in IANA's database are now in the numeric format. See
e.g. https://en.wikipedia.org/wiki/List_of_tz_database_time_zones
The old established zones are naturally still in the traditional alpha-only
format, and they likely cover the majority of actual use now. But sooner or
later more timestamps will start materialising with thezone abbreviation in
the numeric format, so just alpha might not be enough here.
Hannu
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.
