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>
> 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>
> >> 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
> > 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
> > now?
> > BTW, as I read it, PEP 431's biggest contribution was to bring access to
> > 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...
More information about the Datetime-SIG