astimezone() fails on Windows for pre-epoch times

@abalkin

BPO	36759
Nosy	@abalkin, @pganssle, @Windsooon, @jonnyhsu

^{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 = None
closed_at = None
created_at = <Date 2019-04-30.11:36:25.986>
labels = ['3.7', '3.8', 'type-bug', 'library', '3.9']
title = 'astimezone() fails on Windows for pre-epoch times'
updated_at = <Date 2020-03-24.08:53:35.045>
user = 'https://bugs.python.org/Snidhi'

bugs.python.org fields:

activity = <Date 2020-03-24.08:53:35.045>
actor = 'Ard Kuijpers'
assignee = 'none'
closed = False
closed_date = None
closer = None
components = ['Library (Lib)']
creation = <Date 2019-04-30.11:36:25.986>
creator = 'Snidhi'
dependencies = []
files = []
hgrepos = []
issue_num = 36759
keywords = []
message_count = 10.0
messages = ['341149', '341152', '341157', '341236', '342866', '364801', '364866', '364907', '364918', '364921']
nosy_count = 7.0
nosy_names = ['belopolsky', 'SilentGhost', 'p-ganssle', 'Snidhi', 'Windson Yang', 'Jonathan Hsu', 'Ard Kuijpers']
pr_nums = []
priority = 'normal'
resolution = None
stage = 'test needed'
status = 'open'
superseder = None
type = 'behavior'
url = 'https://bugs.python.org/issue36759'
versions = ['Python 3.7', 'Python 3.8', 'Python 3.9']

With: Python 3.6.1 (v3.6.1:69c0db5, Mar 21 2017, 17:54:52) [MSC v.1900 32 bit (Intel)] on win32

import datetime;

d_Time = datetime.datetime.strptime('03:30 PM', '%I:%M %p');
d_Time = d_Time.astimezone(datetime.timezone.utc);
# RESULTS IN OSError: [Errno 22] Invalid argument

# WHEREAS the foll. does not have the issue!
d_Time = datetime.datetime(year    = d_Time.year,
                           month  = d_Time.month,
                           day     = d_Time.day,
                           hour    = d_Time.hour,
                           minute = d_Time.minute,
                           second  = d_Time.second,
                           tzinfo  = datetime.timezone.utc);

print(d_Time);

on macOS 10.14.4, I got ValueError: offset must be a timedelta representing a whole number of minutes, not datetime.timedelta(0, 29143). I will do some research to see why this happen.

This seems like a duplicate (or at least very similar) to the bpo-29097. Could you try a newer version of Python (that issue was fixed in 3.6.7) to make sure it's not a duplicate?

That was specifically a Windows bug, Windson, make sure that what you're seeing is not fixed elsewhere if you only have macOS available.

Thanks, SilentGhost, you are right. I will leave this to a Windows expert instead.

I'm going to close this issue as a duplicate of bpo-29097. If you're still experience this problem on python3.7, please re-open.

Encountered this bug on Python 3.7.6 (default, Jan 8 2020, 20:23:39) [MSC v.1916 64 bit (AMD64)], so on Windows 10. I can reproduce the bug with the code in message https://bugs.python.org/msg341149.

It does not seem to be a duplicate of bpo-29097 since I cannot reproduce that issue.

Yes, I was also able to verify this issue on 3.8.2 on win10. Argument to astimezone is not required, and this happens for both naïve and aware objects.

It would be helpful to have a better error message than '[Errno 22] Invalid argument' on Windows, so a ValueError seems to be a good idea at the moment.

For some reason, for post-epoch values, this works till the year 3001, not 2038:

from datetime import datetime
datetime(3001, 1, 19, 7, 59, 59, 999999).astimezone()  # still works
datetime(3001, 1, 19, 8, 0, 0, 0).astimezone() # fails with 'OSError: [Errno 22] Invalid argument'

run with py 3.9.6

PEP-615 proposes to include the IANA tz database, which would negate the need for a system call. Should we wait for this PEP before fixing this issue? Thoughts?

FWIW, PEP-615 was accepted and became part of Python 3.9 in May 2020, so perhaps this approach is viable now?

FWIW, PEP-615 was accepted and became part of Python 3.9 in May 2020, so perhaps this approach is viable now?

PEP 615 didn't really change anything with respect to this. The issue is that naïve times are local times, and need to be resolved with the system's time zone handling mechanisms. The linked article goes into detail about why it is not sufficient for all use cases to attach a tzinfo that corresponds to "local time" (though individuals are free to do that if they have one of the many very common situations where these concerns don't matter).

This one may be a fundamental limitation of the Windows API, though I doubt it's a major issue, since time zone handling doesn't make nearly as much sense the further back (or forward!) in time you go. It seems unusual for someone to actually care about the answer to the question, "What time zone does this computer think should be attached to a date in local time in 1965?" for example.

Thanks for the insight here re: the Windows API.

It seems unusual for someone to actually care about the answer to the question, "What time zone does this computer think should be attached to a date in local time in 1965?" for example.

In my specific case, we have decades of environmental observations, often made pre-1970, tagged in a database with times in the local time zone for the observation. When retrieving these data we wish to unify them all to GMT/UTC.

In my specific case, we have decades of environmental observations, often made pre-1970, tagged in a database with times in the local time zone for the observation. When retrieving these data we wish to unify them all to GMT/UTC.

Yes, but these observations were not made on the computer you are running the code from, and even if they were, there's nothing that says they were using the set of time zone rules that currently applies on the computer you are running the code from. For code like that you need to either know the UTC time or the local time zone rules that were in effect at the time (or possibly both), and the built-in support for local time would be at best coincidentally useful.

astimezone() fails on Windows for pre-epoch times

Issue fixed by #143463.

vstinner@WIN C:\victor\python\main>python
Python 3.15.0a5+ (heads/main:f5685a266b2, Jan 15 2026, 10:57:22) [MSC v.1944 64 bit (AMD64)] on win32
Type "help", "copyright", "credits" or "license" for more information.
>>> from datetime import datetime
>>> datetime(1969, 1, 1).astimezone()
datetime.datetime(1969, 1, 1, 0, 0, tzinfo=datetime.timezone(datetime.timedelta(seconds=50400), 'Îles de la Ligne (heure d’été)'))

But datetime(3001, 1, 19, 8, 0, 0, 0).astimezone() # fails with 'OSError: [Errno 22] Invalid argument' still fails.

Navigation Menu

Repository navigation

astimezone() fails on Windows for pre-epoch times #80940

2 remaining items

Metadata

Assignees

Labels

Projects

Milestone

Relationships

Development

astimezone() fails on Windows for pre-epoch times #80940

Description

Activity

Snidhi commented on Apr 30, 2019

Windsooon commented on Apr 30, 2019

SilentGhost commented on Apr 30, 2019

Windsooon commented on May 2, 2019

SilentGhost commented on May 19, 2019

ArdKuijpers commented on Mar 22, 2020

SilentGhost commented on Mar 23, 2020

2 remaining items

ArdKuijpers commented on Mar 24, 2020

bariod commented on Oct 4, 2022

dnowacki-usgs commented on Aug 8, 2023

pganssle commented on Aug 9, 2023

dnowacki-usgs commented on Aug 9, 2023

pganssle commented on Aug 9, 2023

vstinner commented on Jan 15, 2026

Metadata

Metadata

Assignees

Labels

Projects

Milestone

Relationships

Development

Issue actions