[Datetime-SIG] Are there any "correct" implementations of tzinfo?
carl at oddbird.net
Tue Sep 15 00:00:32 CEST 2015
On 09/14/2015 03:53 PM, Random832 wrote:
> And if some of them share a common zone, then some of them will work in
> naive time, and some of them will work in aware time, and some pairs
> (well, triples) of them will cause problems for sort/bisect algorithms.
Yep, if you're working with a heterogenous-tzinfo set of aware datetimes
in Python, there may not be a total ordering (and you'll get violations
of various other arithmetic identities, too). Best available option:
don't do that.
> Maybe it'd be best to simply ban interzone comparisons.
Yes, you've got it. Interzone comparisons and arithmetic are the real
wart in the datetime module, once you accept its intended mental model.
If the time machine were in working order, they ought to be banned and
require explicit conversion to the same timezone instead.
> Or have some
> sort of context manager to determine how arithmetic and comparisons
Ouch, please no. If there were a strong desire to support _both_ mental
models of an aware datetime in the Python datetime library, there would
be several better ways to do it (like two different classes for aware
datetimes, or a flag on tzinfo classes, or the - rejected by Guido - PEP
But given the option to "just work in UTC" when you want timeline
arithmetic, and the potential for just multiplying confusion by
providing more mental models, I don't think there's sufficient desire
for that. At least, I've lost such desire as I once may have had ;-)
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 836 bytes
Desc: OpenPGP digital signature
More information about the Datetime-SIG