Skip to content

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

Closed
Closed
datetime.astimezone() method does not handle invalid local times as required by PEP 495#83861
Assignees
abalkin
Labels
3.9 (EOL)end of lifestdlibStandard Library Python modules in the Lib/ directorytype-bugAn unexpected behavior, bug, or error

Description

@abalkin
abalkin
opened on Feb 19, 2020
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

Activity

  1. abalkin commented on Feb 19, 2020

    @abalkin
    abalkin
    on Feb 19, 2020
    MemberAuthor

    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
  2. abalkin
    added
    3.9 (EOL)end of life
    on Feb 19, 2020
  3. abalkin
    self-assigned this
    on Feb 19, 2020
  4. abalkin
    added
    type-bugAn unexpected behavior, bug, or error
    3.9 (EOL)end of life
    on Feb 19, 2020
  5. abalkin
    self-assigned this
    on Feb 19, 2020
  6. abalkin
    added
    type-bugAn unexpected behavior, bug, or error
    on Feb 19, 2020
  7. ezio-melotti
    transferred this issue fromon Apr 10, 2022
  8. serhiy-storchaka
    added this to Date and time issues 🕰️on May 21, 2022

  9. abalkin commented on Feb 2, 2023

    @abalkin
    abalkin
    on Feb 2, 2023
    MemberAuthor

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

  10. abalkin
    added 2 commits that reference this issue on Feb 3, 2023

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

    3b8235a

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

    d3b6683
  11. miss-islington
    added a commit that references this issue on Apr 19, 2023

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

    2b1260c
  12. carljm
    added a commit that references this issue on Apr 20, 2023

    Merge branch 'main' into superopt

    5c0a21c
  13. iritkatriel
    added
    stdlibStandard Library Python modules in the Lib/ directory
    on Nov 28, 2023

  14. encukou commented on Mar 10, 2025

    @encukou
    encukou
    on Mar 10, 2025
    Member

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

  15. encukou
    closed this as completedon Mar 10, 2025
  16. github-project-automation
    moved this to Done in Date and time issues 🕰️on Mar 10, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

Labels

3.9 (EOL)end of lifestdlibStandard Library Python modules in the Lib/ directorytype-bugAn unexpected behavior, bug, or error

Projects

Milestone

No milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions