gh-152248: Reject a POSIX TZ abbreviation with non-ASCII-letter characters in pure-Python zoneinfo

[tonghuaroot]

The pure-Python zoneinfo parser accepts a POSIX TZ string whose unquoted std/dst abbreviation contains characters other than ASCII letters (for example an embedded space or a non-ASCII letter), while the C implementation rejects it. The unquoted alternative in the parser regex is a negated class ([^<0-9:.+-]+) that admits anything except a few delimiters, whereas the C parse_abbr walks the unquoted form with Py_ISALPHA (ASCII letters only), as POSIX (via RFC 8536) requires for the unquoted form.

This tightens the unquoted alternative to [a-zA-Z]+, matching the C accelerator and POSIX, and leaves the quoted <...> form untouched. Every well-formed TZ string and all bundled IANA zones still parse unchanged; only the previously-accepted strings now raise ValueError.

The non-ASCII case is reachable through the public from_file path, which UTF-8-decodes the footer, so it is covered by a dedicated regression test in addition to the whitespace cases added to the shared invalid_tzstrs list.

• Issue: zoneinfo: pure-Python POSIX TZ unquoted abbreviation regex accepts whitespace or non-ASCII letters (C rejects) #152248

[StanFromIreland]

We can give zone_from_tzstr a new parameter for encoding rather than duplicating.

[tonghuaroot]

Done, added an encoding parameter to zone_from_tzstr and reused it. I kept this a separate method only because the C and pure errors differ (bytes repr vs decoded text), so each is matched against its own message.

[StanFromIreland]

And I see another divergence, C accepts an empty <>. :'-(

[tonghuaroot]

Good catch. The direction is the reverse of this PR though: here C is the lenient side. Its parse_abbr quoted branch has no empty check, while its own unquoted branch rejects an empty run (if (str_end == str_start) return -1;), so the pure parser is correct. Want me to fold a small C fix in here, or open a separate issue?

[StanFromIreland]

Please add it here, it's in the scope of POSIX TZ strings. This is actually spelled out by recent versions of the standard:

the quoting characters do not contribute to the three byte minimum length and {TZNAME_MAX} maximum length.

[tonghuaroot]

Done. The C parser now rejects an empty <>, mirroring its unquoted branch.