datetime.astimezone() method does not handle invalid local times as required by PEP 495

[abalkin]

BPO	39680
Nosy	@abalkin, @pganssle

^{Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.}

Show more details

GitHub fields:

assignee = 'https://github.com/abalkin'
closed_at = None
created_at = <Date 2020-02-19.00:56:00.603>
labels = ['type-bug', '3.9']
title = 'datetime.astimezone() method does not handle invalid local times as required by PEP 495'
updated_at = <Date 2020-02-19.00:56:00.603>
user = 'https://github.com/abalkin'

bugs.python.org fields:

activity = <Date 2020-02-19.00:56:00.603>
actor = 'belopolsky'
assignee = 'belopolsky'
closed = False
closed_date = None
closer = None
components = []
creation = <Date 2020-02-19.00:56:00.603>
creator = 'belopolsky'
dependencies = []
files = []
hgrepos = []
issue_num = 39680
keywords = []
message_count = 1.0
messages = ['362241']
nosy_count = 2.0
nosy_names = ['belopolsky', 'p-ganssle']
pr_nums = []
priority = 'normal'
resolution = None
stage = None
status = 'open'
superseder = None
type = 'behavior'
url = 'https://bugs.python.org/issue39680'
versions = ['Python 3.9']

Linked PRs

• gh-83861: Fix datetime.astimezone() method #101545

[abalkin]

Let g be an invalid time in a New York spring-forward gap:

>>> g = datetime(2020, 3, 8, 2, 30)

According to PEP-495, conversion of such instance to UTC should return a value that corresponds to a valid local time greater than g, but

>>> print(g.astimezone(timezone.utc).astimezone())
2020-03-08 01:30:00-05:00

Also, conversion of the same instance with fold=1 to UTC and back should produce a lesser time, but

>>> print(g.replace(fold=1).astimezone(timezone.utc).astimezone())
2020-03-08 03:30:00-04:00

Note that conversion to and from timestamp works correctly:

>>> print(datetime.fromtimestamp(g.timestamp()))
2020-03-08 03:30:00
>>> print(datetime.fromtimestamp(g.replace(fold=1).timestamp()))
2020-03-08 01:30:00

[abalkin]

This bug is still present in the current master:

Python 3.12.0a4+ (heads/main:0675b8f032, Feb  2 2023, 18:31:34) [Clang 14.0.0 (clang-1400.0.29.202)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> import time, os
>>> from datetime import datetime, timezone
>>> os.environ['TZ'] = 'America/New_York'
>>> time.tzset()
>>> time_in_gap = datetime(2020, 3, 8, 2, 30)
>>> print(time_in_gap.astimezone(timezone.utc).astimezone())
2020-03-08 01:30:00-05:00
>>> print(time_in_gap.replace(fold=1).astimezone(timezone.utc).astimezone())
2020-03-08 03:30:00-04:00

Note that the same calculation done with explicit zone info gives correct results:

>>> from zoneinfo import ZoneInfo
>>> New_York = ZoneInfo('America/New_York')
>>> time_in_gap = datetime(2020, 3, 8, 2, 30, tzinfo=New_York)
>>> print(time_in_gap.astimezone(timezone.utc).astimezone(New_York))
2020-03-08 03:30:00-04:00
>>> print(time_in_gap.replace(fold=1).astimezone(timezone.utc).astimezone(New_York))
2020-03-08 01:30:00-05:00

(kudos to @pganssle!)