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.

I'd like to take on this issue if no one else is working on it.

This exception is raised because astimezone() ends up calling time.localtime() to determine the appropriate time zone. If the datetime object has a pre-epoch value, it passes a negative timestamp to time.localtime(). On Windows, time.localtime() does not accept values greater than 0 (more discussion in issue bpo-35796).

This is the minimal code required to reproduce the error:

from datetime import datetime
datetime(1969, 1, 1).astimezone()

Without the ability to ascertain the time zone with localtime(), I'm not sure if the time zone can be accurately determined. It's not clear what the proper behavior is. Maybe raise a ValueError?

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?

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.