gh-152847: Reject POSIX TZ rule with non-digit day-of-year in _zoneinfo.py

[tonghuaroot]

The pure-Python zoneinfo parser validated the Mm.w.d transition rule
strictly, but the Jn (Julian) and n (0-based) day-of-year branches of
_parse_dst_start_end() fell through to a bare int(date) with no format
check. int() accepts input the C accelerator rejects, so the two
implementations disagreed on the same POSIX TZ string.

The C accelerator reads the day-of-year field with
parse_digits(&ptr, 1, 3, &day) in Modules/_zoneinfo.c, consuming 1 to 3
ASCII digits (Py_ISDIGIT) and nothing else. This PR adds the matching guard

if re.fullmatch(r"\d{1,3}", date, re.ASCII) is None:
    raise ValueError(f"Invalid dst start/end date: {dststr}")

before int(), so the pure parser now matches the C accelerator exactly for
this field — not stricter, not looser.

The most notable case is a silent miscompile rather than a crash: int('1_0')
is 10, so AAA4BBB,J1_0,J300/2 previously built a valid but different zone
(DST on day 10) in pure Python while the C accelerator raised ValueError.
The fix also aligns the J+1, leading-space, 4+-digit-width (J0001), and
non-ASCII-digit cases. The 1-to-3-digit bound is deliberate: the C parser
consumes at most three digits, so \d+ would make the pure parser accept
J0001, which C rejects. Leading zeros within three digits (J01, J001)
are still accepted by both. The existing _DayOffset range check
([julian, 365]) is untouched, so no numeric-range behaviour changes.

Verified with a C-vs-pure differential (10 divergent inputs before, 0 after),
a zero-regression pass over all 499 bundled IANA zones (byte-identical through
both implementations), and the full test_zoneinfo suite. Added invalid-TZ
cases (J1_0, 1_0, J+1, J 1, 1, J0001, 0001) and leading-zero
valid controls (J001, 001); these run against both TZStrTest and
CTZStrTest.

This covers a distinct field in the same POSIX TZ parity audit as gh-152212
(std offset), gh-152246 (Mm.w.d separator), and gh-152248 (abbreviation
regex).

• Issue: zoneinfo: pure-Python POSIX TZ Jn/n day-of-year field accepts non-digit input via int() (C rejects) #152847

[StanFromIreland]

Just for the record, quoting RFC 9636:

the TZ environment variable [...] MUST encode the POSIX portable character set as ASCII

This is what the C accelerator currently complies with.

[StanFromIreland]

LGTM, one little nit.

[miss-islington-app]

Thanks @tonghuaroot for the PR, and @StanFromIreland for merging it 🌮🎉.. I'm working now to backport this PR to: 3.13.
🐍🍒⛏🤖

[miss-islington-app]

Thanks @tonghuaroot for the PR, and @StanFromIreland for merging it 🌮🎉.. I'm working now to backport this PR to: 3.14.
🐍🍒⛏🤖

[miss-islington-app]

Thanks @tonghuaroot for the PR, and @StanFromIreland for merging it 🌮🎉.. I'm working now to backport this PR to: 3.15.
🐍🍒⛏🤖

[bedevere-app]

GH-152908 is a backport of this pull request to the 3.13 branch.

[bedevere-app]

GH-152909 is a backport of this pull request to the 3.14 branch.

[bedevere-app]

GH-152910 is a backport of this pull request to the 3.15 branch.

[StanFromIreland]

Merged, thanks.