| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
| |
Co-authored-by: Serhiy Storchaka <storchaka@gmail.com>
|
| |
|
|
|
| |
Determine the support of the Kyiv timezone by checking the result of
astimezone() which uses the system tz database and not the one
populated by zoneinfo.
|
| |
|
|
|
|
|
|
|
|
|
|
| |
tzdata provides Kiev as an alternative to Kyiv:
https://sources.debian.org/src/tzdata/2023c-10/backward/?hl=314#L314
But Debian moved it to the tzdata-legacy package breaking the test:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1050530
This patch switches to the name provided by tzdata.
Also check that the new name is actually available.
|
| |
|
|
|
| |
This reverts commit 7659128b9d7a30ddbcb063bc12e2ddb0f1f119e0.
It broke tests on the Debian and macOS buildbots.
|
| |
|
|
|
|
|
|
|
|
|
| |
tzdata provides Kiev as an alternative to Kyiv:
https://sources.debian.org/src/tzdata/2023c-10/backward/?hl=314#L314
But Debian moved it to the tzdata-legacy package breaking the test:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1050530
This patch switches to the name provided by tzdata.
|
| | |
|
| |
|
|
| |
Co-authored-by: wouter bolsterlee <wouter@bolsterl.ee>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
I am re-submitting an older PR which was abandoned but is still relevant, #10783 by @timb07.
The issue being solved () is still relevant. The original PR #10783 was closed as
the final request changes were not applied and since abandoned.
In this new PR I have re-used the original patch plus applied both comments from the review, by @maxking and @pganssle.
For reference, here is the original PR description:
In email.utils.parsedate_to_datetime(), a failure to parse the date, or invalid date components (such as hour outside 0..23) raises an exception. Document this behaviour, and add tests to test_email/test_utils.py to confirm this behaviour.
In email.headerregistry.DateHeader.parse(), check when parsedate_to_datetime() raises an exception and add a new defect InvalidDateDefect; preserve the invalid value as the string value of the header, but set the datetime attribute to None.
Add tests to test_email/test_headerregistry.py to confirm this behaviour; also added test to test_email/test_inversion.py to confirm emails with such defective date headers round trip successfully.
This pull request incorporates feedback gratefully received from @bitdancer, @brettcannon, @Mariatta and @warsaw, and replaces the earlier PR #2254.
Automerge-Triggered-By: GH:warsaw
|
| |
|
|
|
| |
Fix mktime() overflow error in test_email: run
test_localtime_daylight_true_dst_true() and
test_localtime_daylight_false_dst_true() with a specific timezone.
|
| |
|
|
| |
Leopard because this OS uses out of date (pre 2011k) timezone files.
|
| |
|
|
| |
Patch from Dmitry Shachnev.
|
| | |
|
| | |
|
| |
|
|
| |
Use year 1990 instead of year 1970 to avoid issues with negative timestamps.
|
| | |
|
| |
|
|
|
|
|
| |
The new code correctly handles historic changes in UTC offsets.
A test for this should follow.
Original patch by Alexander Belopolsky.
|
| |
|
|
|
|
|
|
| |
Without this function people would be tempted to use the other date functions
in email.utils to compute an aware localtime, and those functions are not as
good for that purpose as this code. The code is Alexander Belopolsy's from
his proposed patch for issue 9527, with a fix (and additional tests) by Brian
K. Jones.
|
| |
|