public inbox for libc-alpha@sourceware.org
 help / color / mirror / Atom feed
From: Paul Eggert <eggert@cs.ucla.edu>
To: Wilco Dijkstra <Wilco.Dijkstra@arm.com>,
	"lancasterharp@gmail.com" <lancasterharp@gmail.com>
Cc: 'GNU C Library' <libc-alpha@sourceware.org>
Subject: Re: Fix %Z parsing in strptime [BZ #16088]
Date: Mon, 17 Jul 2023 10:19:20 -0700	[thread overview]
Message-ID: <58af583d-41b7-5e23-75e6-d88f8a5be3ec@cs.ucla.edu> (raw)
In-Reply-To: <PAWPR08MB8982F972C45EC77F64AEC132833BA@PAWPR08MB8982.eurprd08.prod.outlook.com>

On 2023-07-17 05:57, Wilco Dijkstra via Libc-alpha wrote:
> Hi Stanley,
> 
>> +	  /* we recognize the format [-+a-zA-Z0-9]{3,} */
> 
> Is that really the correct format? Eg. should it be able to parse UTC offsets like UTC+04:30?

strftime doesn't generate such offsets, so this is asking whether 
strptime should accept forms that strftime doesn't generate, at the cost 
of strptime misparsing some unusual forms that strftime does generate 
(e.g., strftime with "%Z:%Y").


> This is basically isalnum() but not allowing '+' or '-'.

Yes, '+' and '-' should be allowed.


> rather than allowing any sequence of these characters, would it
> not be better to scan just for isalpha() first, and only if you see '+' or '-' check the UTC
> offset syntax?

POSIX allows settings like TZ='<-X->0', unfortunately, which generate 
time zone abbreviations like "-X-". Also, an actual isalpha would be 
dicey, as abbreviations use ASCII letters (OK, letters in the POSIX 
locale, basically the same thing), so it's arguably better to avoid 
isalpha here.

  reply	other threads:[~2023-07-17 17:19 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-07-17 12:57 Wilco Dijkstra
2023-07-17 17:19 ` Paul Eggert [this message]
  -- strict thread matches above, loose matches on Subject: below --
2023-07-14 14:52 Stanley Lancaster
2023-07-14 16:11 ` Paul Eggert
2023-07-18 17:17   ` Stanley Lancaster
2023-07-18 17:22     ` Stanley Lancaster
2023-07-19  2:13     ` Paul Eggert

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=58af583d-41b7-5e23-75e6-d88f8a5be3ec@cs.ucla.edu \
    --to=eggert@cs.ucla.edu \
    --cc=Wilco.Dijkstra@arm.com \
    --cc=lancasterharp@gmail.com \
    --cc=libc-alpha@sourceware.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).