While PEP 495 is primarily about improving the tzinfo interface, it proposes one feature that will be visible to datetime users who don't write their own tzinfo implementations or use any from a third party. This feature is described in the section "Conversion from Naive to Aware" [1] and will enable users to call astimezone() method on naive instances to convert them to aware.
The PEP proposes that naive datetimes should be presumed by astimezone() to be in system local timezone similarly to the way they are treated in the timestamp() method now.
This feature has been criticized because "Treating a naive datetime as being a local time is as senseless as treating it as a UTC time - it's arbitrary." [2]
The proposed changes to astimezone() will make it discriminate between the two arbitrary choices. Converting a naive datetime to say UTC timezone assuming it is local will become
>>> dt.astimezone(timezone.utc)
but the same conversion assuming dt is already in UTC is done by
>>> dt.replace(tzinfo=timezone.utc)
The asymmetry is more visible in when the task is to imbue a naive datetime with an appropriate local fixed offset timezone:
>>> dt.astimezone() # assuming dt is local
vs.
>>> dt.replace(tzinfo=timezone.utc).astimezone() # assuming dt is UTC
As an alternative to an implicit local timezone, we can provide an explicit timezone.local implementation and tell users to write
>>> dt.replace(tzinfo=timezone.local).astimezone() # assuming dt is local
making working with implicitly local and implicitly UTC naive instances equally inconvenient.
Furthermore, implicit local time zone logic is already implemented with respect to the target timezone: to convert to a local (fixed offset) timezone astimezone() is called without arguments, but any other timezone needs to be provided explicitly, including timezone.utc.
IMO, if nondiscrimination between between UTC and local is important, I would rather add utcastimezone() and utctimestamp() methods that will work like their namesakes but assume that the instances they are invoked on are in UTC.
Please discuss.