Support Internet RFC 8536 TZif files #1091
Conversation
These are generated by modern-day zic, and zic -b slim takes advantate of this format. * ci_tools/run_tz_master_env.sh: * dateutil/zoneinfo/rebuild.py: Revert recent change that insisted on slim TZif files, since the code now works on both fat and slim. * dateutil/parser/_parser.py: Add support for POSIX-2001 TZ strings, which can contain < and >. Add support for RFC 8536 extensions to TZ strings, which allow negative times in DST transitions. * dateutil/test/test_tz.py: 'WART4WARST,J1,J365/-25' is now valid due to RFC 8536 section 3.3.1, so add another '-'. to make it invalid. * dateutil/tz/tz.py: Add support for TZif versions 2 and 3, which have 64-bit timestamps, TZ strings for far-future timestamps, and TZ strings involving negative transition times.
|
After creating this PR Github reports "Some checks were not successful", but looking at the details these all appears to be problems with the Github CI (e.g., "We are currently unable to download the log. Please try again later.") rather than actual bugs with the PR. |
|
Hm.. My plan was to actually backport as much of the pure Python logic from That said, there are no tests for this (and I do have a fairly extensive test suite for I'll try and prioritize this soon, either by finishing the |
|
Oh, and I forgot to say thank you for taking the time to prepare this PR. It's very appreciated. |
Yes, that would be nice as well. I did it by hand as I hoped these changes would be smaller and easier to audit. At some point I suppose I should try to get
There are tests, in that if you run the test suite on a platform where 'zic' defaults to 'zic -b slim', the changes are pretty thoroughly tested because 'zic -b slim' omits all 32-bit transitions and relies heavily on the TZ string at the end. That's how I tested the change (I also tested 'zic -b fat' of course). It would be nice to arrange to test the code with both 'zic -b fat' and 'zic -b slim' on all platforms that support 'zic -b', but I hope it's OK if I leave that detail up to you.... |
dateutil still isn't ready. Bug: https://bugs.gentoo.org/747538 Bug: dateutil/dateutil#1059 Bug: dateutil/dateutil#1091 Bug: dateutil/dateutil#1130 Signed-off-by: Sam James <sam@gentoo.org>
|
I copy/pasted the tz.py and _parser.py on top of existing versions used by a django project and they produce correct answer for this test case, attached. It is the US election day recurrence in the doc, run out to 2060, which is the first time after 2038 when daylight time has not ended (for future reference, daylight time ends on the first Sunday in November, and election day is the Tuesday after the first Monday.) |
|
@CraigeHales I wonder: Could you create a separate pull request, if required based on this one? A zip file is more likely to be lost. |
These are generated by modern-day zic, and zic -b slim
takes advantate of this format.
Revert recent change that insisted on slim TZif files,
since the code now works on both fat and slim.
Add support for POSIX-2001 TZ strings, which can contain < and >.
Add support for RFC 8536 extensions to TZ strings, which
allow negative times in DST transitions.
due to RFC 8536 section 3.3.1, so add another '-'. to make it
invalid.
have 64-bit timestamps, TZ strings for far-future timestamps,
and TZ strings involving negative transition times.
Summary of changes
Closes
Pull Request Checklist