On Tue, Sep 8, 2015 at 12:41 PM, Tim Peters <[email protected]> wrote:
> [Alex] > > ... > > Once you decide to use a post-PEP tzinfo, you have no choice but to test > > your software on the edge cases if you care about them. > > Which reminds me: the PEP should add a way for a post-495 tzinfo to > say it supplies post-495 semantics, so users can check whether they're > getting a tzinfo they require (if they need fold disambiguation) or > can't tolerate (if they need folds to be ignored for legacy reasons). > We may end up providing something like this, but I hope developing this mechanism can be left to the tzinfo implementers. (Which can as well be us, but in another PEP.) I am not sure a tzinfo object will need a persistent attribute rather than just a way to require specific capabilities at the construction time. For example, a hypothetical zoneinfo() constructor or a factory function can take a "fold_aware" boolean argument and let the user specify what kind of tzinfo is requested. It will then become a QOI issue of whether zoneinfo() supports both pre- and post-PEP semantics or not. Note that zoneinfo() providers may end up extending the tzinfo API to include queries such as give me all folds between year A and year B. The downside of a persistent run-time attribute that differentiate between pre-PEP and post-PEP tzinfos is that it may promote writing code that tries to cope with the presence of pre-PEP and post-PEP tzinfos in the same program. This is a recipe for a combinatorial disaster. Note that on top of pre-PEP/post-PEP distinction a good tzinfo() library will probably also supply a TZ database version. Imagine writing a simple "within(t, start, stop)" function that should account for the tree arguments possibly having different "fold_aware" attribute and different tzversion? > > It's not a change to the tzinfo API, but is a change to tzinfo semantics. > > I guess requiring a new `__version__ = 2` attribute would be OK. > I generally dislike "version" constants or attributes. My preferred solution would be to provide a generic PEP 495 compliant fromutc() in a tzinfo subclass and ask PEP 495 compliant implementations to derive from that. > > Or (preferably "and") add an optional `fold=None` argument to > .utcoffset() (by default, use the datetime's .fold attribute, else > use the passed value). I thought about this as an optimization. dt.utcoffset(fold=1) being an equivalent of dt.replace(fold=1).utcoffset() which avoids copying of the entire dt object into a temporary. I think this is a minor issue. I can go either way on this. > Then an obscure form of version-checking could > be done by seeing whether dt.utcoffset(fold=1) blows up. I would not add dt.utcoffset(fold=x) just for that and if we end up adding it for other reasons will probably consider such use a hack. > That's a > poor way to spell "check the version", but would at least allow > checking to see what would happen if `fold` changed without the > expense of creating new short-lived datetime objects. Yes, this is a good reason and since calling utcoffset() both ways will be typical for "careful" applications, I don't mind giving them some syntactic sugar for that. Yet again, this is not a "live or die" issue for PEP 495.
_______________________________________________ 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/
