[Datetime-SIG] PEP-431/495

Guido van Rossum guido at python.org
Mon Aug 24 02:42:59 CEST 2015


On Sat, Aug 22, 2015 at 10:46 PM, Stuart Bishop <stuart at stuartbishop.net>
wrote:

> On 23 August 2015 at 04:46, Chris Barker <chris.barker at noaa.gov> wrote:
> > On Sat, Aug 22, 2015 at 11:55 AM, Tim Peters <tim.peters at gmail.com>
> wrote:
> >
> >>
> >>  What we're left with
> >> appears to be just one other bit, spelled via the presence or absence
> >> of a new magic attribute on a tzinfo instance, or via inheritance or
> >> non-inheritance from a new marker class.  That new bit is used to
> >> spell "classic or timeline arithmetic?" (which datetime internals -
> >> not tzinfos - will be required to implement).
> >
> >
> > if it would be implemented by datetime, or a datetime subclass, wouldn't
> it
> > make sense for that attribute to be on the datetime instance, rather
> than a
> > tzinfo instance?
> >
> > Anyway, I have an interest in seeing that done -- and Alexander is
> right, it
> > would be better to make whatever changes we need to datetime now in a way
> > that will last.
> >
> > so is it time to add an attribute to specify "timeline" arithmetic
> somewhere
> > now?
> >
> > BTW, as I read it, PEP 431's biggest contribution was to bring access to
> a
> > timezone database into the stdlib -- is that idea dead?
>
> Putting a database updated a dozen times per year, often at short
> notice, into stdlib is a bad idea. Putting the necessary tzinfo
> implementations to read the existing timezone database on your
> platform is a great idea, as is distributing the Olson timezone
> database via pip for less well endowed platforms. And a 'local' tzinfo
> instance is pretty much a requirement. I ty to move as much as pytz
> and Lennart's tzlocal into stdlib as possible. Exactly how that
> happens depends on the outcome of this PEP-495. Ideally, pytz will
> cease to be required at all because Python stdlib will be able to give
> you unambiguous, correct datetime arithmetic ('timeline') out of the
> box using the timezone database installed on your system. I robot can
> push the zoneinfo database to pypi, or I will until the robot is
> setup. On Python 3.whatever, the pytz library will just wrap stdlib to
> provide backwards compatibility.
>
> Failing the ideal situation, pytz will remain for users needing
> timeline arithmetic but will still offload what it can to stdlib and
> no longer require use of the localize() and normalize() methods (ie.
> it will work as you expect, not as it does today).
>

Apart from the breathless rendition that's pretty much the hope, yes. Would
going forward with PEP 495 as it currently stands (a single bit to
distinguish ambiguous times) be a problem? I would really like to finish
this endless (oh irony, when talking about time :-) discussion.

-- 
--Guido van Rossum (python.org/~guido)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/datetime-sig/attachments/20150823/9987ffb6/attachment.html>


More information about the Datetime-SIG mailing list