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

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

@pganssle

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!)

Fix datetime.astimezone() method (pythongh-83861)

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

Merge branch 'main' into superopt

The PR was merged for 3.12, so I'll close.

Navigation Menu

Repository navigation

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

Linked PRs

Metadata

Assignees

Labels

Projects

Milestone

Relationships

Development

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

Description

Linked PRs

Activity

abalkin commented on Feb 19, 2020

abalkin commented on Feb 2, 2023

encukou commented on Mar 10, 2025

Metadata

Metadata

Assignees

Labels

Projects

Milestone

Relationships

Development

Issue actions