[Datetime-SIG] Version check (was Re: PEP 495: What's left to resolve)

[Tim Peters]

[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).

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.

Or (preferably "and") add an optional `fold=None` argument to
.utcoffset()  (by default, use the datetime's .fold attribute, else
use the passed value).  Then an obscure form of version-checking could
be done by seeing whether dt.utcoffset(fold=1) blows up.  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.  Like:

>    v_self = n_self - self.replace(fold=(1-self.fold)).utcoffset()

becoming:

    v_self = n_self - self.utcoffset(fold=1-self.fold)

It seems the worst way to spell "check the version" is the status quo,
where it seems a user would have to contrive a case where `fold`
matters.  While that's usually an excellent way ("check for the
behavior you actually require"), in this case it means the user would
have to know too much (e.g., how do they get a tzinfo representing a
multi-offset zone to begin with?  far as I know, there's no portable
way to ask for that - then, even if they solve that, they need to know
exactly where to find an ambiguous time in that zone).