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.

classification
Title: timezone allows no offset from range (23:59, 24:00)
Type: behavior Stage: resolved
Components: Library (Lib) Versions: Python 3.9, Python 3.8, Python 3.7
process
Status: closed Resolution: fixed
Dependencies: Superseder:
Assigned To: Nosy List: belopolsky, joernheissler, p-ganssle, xtreak
Priority: normal Keywords: patch

Created on 2019-07-21 11:41 by joernheissler, last changed 2022-04-11 14:59 by admin. This issue is now closed.

Pull Requests
URL Status Linked Edit
PR 14878 merged nsiregar, 2019-07-21 14:02
PR 15226 merged p-ganssle, 2019-08-12 14:25
PR 15227 merged p-ganssle, 2019-08-12 14:30
Messages (6)
msg348237 - (view) Author: Jörn Heissler (joernheissler) * Date: 2019-07-21 11:41
https://bugs.python.org/issue5288 changed datetime.timezone to accept sub-minute offsets.

The C implementation allows offsets from range (23:59, 24:00) while the python implementation does not:

# C
>>> timezone(timedelta(seconds=86399))
datetime.timezone(datetime.timedelta(seconds=86399))

# Python
>>> timezone(timedelta(seconds=86399))
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "cpython/Lib/datetime.py", line 2194, in __new__
    raise ValueError("offset must be a timedelta "
ValueError: offset must be a timedelta strictly between -timedelta(hours=24) and timedelta(hours=24).

This is because _maxoffset is defined as timedelta(hours=23, minutes=59)

Second issue: The (undocumented) "min" and "max" attributes (both C and python) show 23:59
even though the C implementation can get closer to 24:00.
Should this be changed to timezone(timedelta(seconds=86399, microseconds=999999))?


(Same applies to the minimums)
msg348242 - (view) Author: Paul Ganssle (p-ganssle) * (Python committer) Date: 2019-07-21 12:37
I agree that the C and Python behavior should be the same, and both of them should allow all offsets less than 24 hours. I'm actually quite surprised we don't have a test for this in `datetimetester.py`.
msg348298 - (view) Author: Paul Ganssle (p-ganssle) * (Python committer) Date: 2019-07-22 14:01
I have been thinking about this more and I think the two issues (`min` and `max` vs. the incompatibility between C and Python) should be considered two separate issues.

My reasoning is that a change of the value of `timezone.min` and `timezone.max` is not something I'd be comfortable backporting to 3.7, because it has the potential to cause failures in some test suites (for example, `datetime.now(tz=datetime.timezone.max).isoformat()` will start returning a string that does not conform to ISO 8601, which has no support for sub-minute offsets). However, differences between the C and Python implementations are a violation of at least the spirit of PEP 399 and I think it should be backported to 3.7.
msg349290 - (view) Author: Paul Ganssle (p-ganssle) * (Python committer) Date: 2019-08-09 14:22
New changeset 92c7e30adf5c81a54d6e5e555a6bdfaa60157a0d by Paul Ganssle (Ngalim Siregar) in branch 'master':
bpo-37642: Update acceptable offsets in timezone (GH-14878)
https://github.com/python/cpython/commit/92c7e30adf5c81a54d6e5e555a6bdfaa60157a0d
msg349816 - (view) Author: Paul Ganssle (p-ganssle) * (Python committer) Date: 2019-08-15 19:09
New changeset 27b38b99b3a154fa5c25cd67fe01fb4fc04604b0 by Paul Ganssle in branch '3.8':
bpo-37642: Update acceptable offsets in timezone (GH-14878) (#15227)
https://github.com/python/cpython/commit/27b38b99b3a154fa5c25cd67fe01fb4fc04604b0
msg349817 - (view) Author: Paul Ganssle (p-ganssle) * (Python committer) Date: 2019-08-15 19:09
New changeset ed44b84961eb0e5b97e4866c1455ac4093d27549 by Paul Ganssle in branch '3.7':
bpo-37642: Update acceptable offsets in timezone (GH-14878) (#15226)
https://github.com/python/cpython/commit/ed44b84961eb0e5b97e4866c1455ac4093d27549
History
Date User Action Args
2022-04-11 14:59:18adminsetgithub: 81823
2019-08-15 19:11:42p-gansslesetstatus: open -> closed
resolution: fixed
stage: patch review -> resolved
2019-08-15 19:09:40p-gansslesetmessages: + msg349817
2019-08-15 19:09:10p-gansslesetmessages: + msg349816
2019-08-12 14:30:09p-gansslesetpull_requests: + pull_request14951
2019-08-12 14:25:48p-gansslesetpull_requests: + pull_request14950
2019-08-09 14:22:21p-gansslesetmessages: + msg349290
2019-07-22 14:01:30p-gansslesetmessages: + msg348298
2019-07-21 14:02:26nsiregarsetkeywords: + patch
stage: needs patch -> patch review
pull_requests: + pull_request14664
2019-07-21 13:34:40xtreaksetnosy: + xtreak
2019-07-21 12:37:07p-gansslesetmessages: + msg348242
stage: needs patch
2019-07-21 11:44:40xtreaksetnosy: + belopolsky, p-ganssle
2019-07-21 11:41:24joernheisslercreate