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

[Random832]

On Mon, Sep 14, 2015, at 16:27, Alexander Belopolsky wrote:
> You've never specified "this invariant", 

I have specified it numerous times.

> but I'll assume you are talking
> about "a < b implies a.astimezone(UTC) < b.astimezone(UTC)."  This is
> *not*
> true today:

In my first few posts about the issue I did note "mid-spring-forward"
times as an exception (and I assert that they are the *only* exception).
But repetition and having to keep explaining this has worn me down.

> >>> from datetime import *
> >>> from datetimetester import Eastern
> >>> UTC = timezone.utc
> >>> a = datetime(2002, 4, 7, 1, 40, tzinfo=Eastern)
> >>> b = datetime(2002, 4, 7, 2, 20, tzinfo=Eastern)
> >>> a < b
> True
> >>> a.astimezone(UTC) < b.astimezone(UTC)
> False

I don't know how your datetimetester works, so this is a bit of a black
box to me - correct me if any of the below is wrong:

I assume that 2002-04-07 is the morning of the "spring forward"
transition of that year. Therefore, it's worth noting, the time in "b"
is one that doesn't actually exist. I actually did mention, in one of my
messages on the subject, that "spring forward" times were an exception -
the *only* exception, to the invariant, but that's been lost in a few of
my repetitions.

I'm going to assume that the interpretations that led to your results
are:
a = 2002-04-07 01:40:00 -0500 = 2002-04-07 06:40:00 Z
b = 2002-04-07 02:20:00 -0400 = 2002-04-07 06:20:00 Z

I don't think this is a reasonable value for b.astimezone(UTC) to have.

But anyway, none of this is actually relevant to my claims about how the
times near "fall back" transitions (i.e. with different fold values)
should be sorted. I wasn't at any point proposing *actually* converting
to UTC as part of the mechanism for comparing times. Just that having
times near "fold" points ordered in any other way would be surprising
and unreasonable.