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