On Thu, Sep 3, 2015 at 11:19 AM, Carl Meyer <[email protected]> wrote:
> > This is unavoidable because > > within the same timezone fold=1 instances don't exist: 01:59 is followed > > by 02:00 with no room for "second 01:30" in between. > > Right. That's an excellent statement of why respecting `fold` at all is > inconsistent with how tz-annotated datetimes are designed to behave in > Python (they operate internally in naive time, in which the "fold" time > does not even exist). I wish we could have a design where fold is always ignored when you have a single tzinfo. The reason we cannot has been explained several times in this thread. The core reason is possibly a mistake in the original design that permitted cross-zone arithmetic and comparison. If == was defined so that no two instances with different tzinfo ever compare equal and <, - and friends are only defined for datetimes sharing the tzinfo, we would not have this problem. Recall that datetime was designed at the time when it was thought that mixing bytes and unicode was a good idea. We all know what it took to fix that wart. I don't think cross-zone datetime arithmetic is an issue of the same scale or impact.
_______________________________________________ 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/
