Tim Peters <t...@python.org> added the comment:
I copy/pasted the definitions of "aware" and "naive" from the docs. Your TZ's
.utcoffset() returns None, so, yes, any datetime using an instance of that for
its tzinfo is naive.
In
print(datetime(2000,1,1).astimezone(timezone.utc))
the docs for astimezone say, in part,
"""
If self is naive (self.tzinfo is None), it is presumed to represent time in the
system timezone.
"""
So it converted your naive time (viewed as being in your system - EDT - time
zone) to UTC.
That appears to be using a different definition of "naive" (looking only at
whether self.tzinfo is None).
The original datetime.py certainly didn't do that ...
"""
def astimezone(self, tz):
if not isinstance(tz, tzinfo):
raise TypeError("tz argument must be an instance of tzinfo")
mytz = self.tzinfo
if mytz is None:
raise ValueError("astimezone() requires an aware datetime")
if tz is mytz:
return self
# Convert self to UTC, and attach the new time zone object.
myoffset = self.utcoffset()
if myoffset is None:
raise ValueError("astimezone() requires an aware datetime")
"""
So it originally used the definition I quoted first. The "sometimes pretend
it's local time anyway" twist appeared to get added here:
https://github.com/python/cpython/commit/fdc860f3106b59ec908e0b605e51a1607ea2ff4b
----------
_______________________________________
Python tracker <rep...@bugs.python.org>
<https://bugs.python.org/issue33812>
_______________________________________
_______________________________________________
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
