This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author tim.peters
Recipients belopolsky, tim.peters
Date 2018-06-09.03:31:21
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1528515082.1.0.592728768989.issue33812@psf.upfronthosting.co.za>
In-reply-to
Content
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
History
Date User Action Args
2018-06-09 03:31:22tim.peterssetrecipients: + tim.peters, belopolsky
2018-06-09 03:31:22tim.peterssetmessageid: <1528515082.1.0.592728768989.issue33812@psf.upfronthosting.co.za>
2018-06-09 03:31:22tim.peterslinkissue33812 messages
2018-06-09 03:31:21tim.peterscreate