[Datetime-SIG] Adding PEP 495 support to dateutil

Alexander Belopolsky alexander.belopolsky at gmail.com
Sat Sep 19 07:09:01 CEST 2015

On Fri, Sep 18, 2015 at 11:19 PM, Akira Li <4kir4.1i at gmail.com> wrote:

> It was
> a reaction to the earlier message in this thread, to point out why
> stdlib's fromutc() API is not the example that should be followed.

You don't have to "follow" it but you must understand what datetime module
expects from you as a tzinfo implementer if you decide to override the
default fromutc() implementation.  What Stuart did in pytz was a hack that
the authors of the original design did not expect.

I think you find fromutc() design unnatural because you have a different
view of what datetime instances are.  I believe for you, datetime instances
are labels on a time line, but they are not.  They are more like clock
faces.  Aware datetimes are clocks with stickers that say "New York",
"Madrid", etc.  The label tells you how to interpret the time that the
clock shows, but that time does not have to be "current" or "accurate" time
at the location written on the label.  You can take a "Madrid" clock and
set it to show "current" New York time.  Nothing in datetime module will
stop you even if you set the time that falls in Madrid "gap" and makes no
sense there.

The fromutc() method helps you to set your New York clock if you know
"current" UTC time.  The instructions are simple: set "current" UTC time on
your New York clock and call fromutc().

If you adopt this mental picture, then the idea of replacing tzinfo on a
datetime becomes absurd.  Why would you want ruin a perfectly good "New
York" clock simply because it comes from Geneva showing time that is 5
hours ahead?  You don't rip off the "New York" label - you just wind the
clock back 5 hours.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/datetime-sig/attachments/20150919/4c6d7a28/attachment.html>

More information about the Datetime-SIG mailing list