Paul Ganssle <p.gans...@gmail.com> added the comment:
> This sounds like a bug. Whether a tzinfo is a constant from a predefined set > or something with a smart comparison semantic is none of datetime's business. I'm not sure what you mean, but it was not a "bug" in the sense that it was accidental, it was a deliberate choice. It comes at least partially from the fact that arithmetic operations attach the same timezone object to the new datetimes they create. When I first found out about this behavior, I raised bpo 28601. In any case, it's a side issue here, there are many other reasons pytz's model is incompatible with the preferred time zone model. ---------- _______________________________________ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue35723> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
