On Mon, Sep 14, 2015, at 15:25, Alexander Belopolsky wrote: > This is a fine attitude when you implement your own brand new datetime > library. As an author of a new library you have freedoms that developers > of a 12 years old widely deployed code don't have.
I'm talking about the real behavior of datetime as it exists *today*, and has existed for the past 12 years, before any of this "add fold flag but sort 2:15 fold1 before 2:45 fold0" nonsense gets in. It is an invariant that is true today, and therefore which you can't rely on any of the consumers of this 12 years old widely deployed code not to assume will remain true. Enforcing an invariant that all ordering is done according to UTC timestamps would not break any backward compatibility, because there is not a *single* pair of timestamps that can be represented today with any *remotely* plausible tzinfo whose order is different from that. For that matter, a tzinfo where two possible values for fold aren't sufficient to disambiguate timestamps is *more* plausible than one where the naive ordering of any two non-fold timestamps is reversed from the UTC order, yet that case apparently isn't being considered. -- https://mail.python.org/mailman/listinfo/python-list
