On Sat, Aug 22, 2015 at 10:46 PM, Stuart Bishop <[email protected]> wrote:
> On 23 August 2015 at 04:46, Chris Barker <[email protected]> wrote: > > On Sat, Aug 22, 2015 at 11:55 AM, Tim Peters <[email protected]> > 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)
_______________________________________________ Datetime-SIG mailing list [email protected] https://mail.python.org/mailman/listinfo/datetime-sig The PSF Code of Conduct applies to this mailing list: https://www.python.org/psf/codeofconduct/
