[Datetime-SIG] PEP 495: Conversion from naive to aware

Alexander Belopolsky alexander.belopolsky at gmail.com
Sat Aug 29 01:29:58 CEST 2015

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


>>> 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.

[2]: https://mail.python.org/pipermail/datetime-sig/2015-August/000464.html
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/datetime-sig/attachments/20150828/af069054/attachment-0001.html>

More information about the Datetime-SIG mailing list