[Datetime-SIG] Are there any "correct" implementations of tzinfo?

[Random832]

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.