This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author p-ganssle
Recipients p-ganssle
Date 2020-12-16.21:33:53
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1608154433.49.0.318883425805.issue42663@roundup.psfhosted.org>
In-reply-to
Content
TZif files consist of a list of transitions followed by a POSIX TZ var-style string of a form like "AAA3BBB,M3.2.0/01:30,M11.1.0/02:15:45", which decodes to "AAA (UTC-3) is the standard time and BBB (UTC-2) is the DST time, DST applies starting at 02:15:45 local time on the 1st Sunday in November and ending at 1:30:00 local time on the 2nd Sunday in March". After the last listed transition, the rule specified by the TZ variable applies.

POSIX says that the "hours" part of the transition rule must be in the range ±24, but as mentioned in a TODO comment in _zoneinfo.c, RFC 8536 §3.3.1 specifies that the hours part of transition times may range from -167 to 167 (see: https://github.com/python/cpython/blob/master/Modules/_zoneinfo.c#L1844-L1847 ).

Currently, zoneinfo does not support the full range of possible transitions, and a TZif file with a 3-digit transition hour would likely fail to parse. This isn't a terribly high priority at the moment, but if the tz project ever releases a TZif file with one of these TZ strings on it, it will all of a sudden become very critical to fix it, so we should probably try to get it fixed before Python 3.9 is EOL, so that all versions of Python with `zoneinfo` can handle this properly.
History
Date User Action Args
2020-12-16 21:33:53p-gansslesetrecipients: + p-ganssle
2020-12-16 21:33:53p-gansslesetmessageid: <1608154433.49.0.318883425805.issue42663@roundup.psfhosted.org>
2020-12-16 21:33:53p-gansslelinkissue42663 messages
2020-12-16 21:33:53p-gansslecreate