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 > work. 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 500). 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 ;-) Carl
signature.asc
Description: OpenPGP digital signature
_______________________________________________ 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/
