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

[Tim Peters]

[Random832 <random832 at fastmail.com>]
> A) I'm still not sure why, but I was talking about adding an int, not a
> timedelta and a string.
>
> B) Older python versions can't make use of either utcoffset or fold, but
> can ignore either of them. I don't even see why they couldn't ignore a
> timedelta and a string if we felt like adding those.

Because all versions of Python expect a very specific pickle layout
for _every_ kind of pickled object (including datetimes)..  Make any
change to the pickle format of any object, and older Pythons will
simply blow up (raise an exception) when trying to load the new pickle
- or do something insane with the pickle bits.  It's impossible for
older Pythons to know anything about what "the new bits" are supposed
to mean, and there is no way to spell, in the pickle engine, "but if
you're an older version, skip over the next N bytes".


> C) What value fold "should" have can be inferred from the time, the
> utcoffset, and the tzinfo.

So you are proposing to add ... something ... _instead_ of adding
`fold`.  Already addressed that.  See above.

> I'm saying that *today*, even with no 495, it [utcoffset] does provide
> *a* value in all cases (even if that's sometimes the "wrong" value
> for an ambiguous time).

Sure.

> And that value is, for any plausible tzinfo, ordered the same for
> any given pair of datetimes with the same tzinfo as the datetimes
> considered as naive datetimes.

Yes.

> There is, or appears to be, a faction that is proposing to change that
> by sorting fold=1 2:15 before fold=0 2:45 even though the former is
> *actually* 30 minutes later than the latter, and I am *utterly baffled*
> at why they think this is a good idea.

It's not so much a "good idea" as that it's the only idea consistent
with Python's "naive time" model.  Folds and gaps don't exist in naive
time.  Indeed, the _concept_ of "time zone" doesn't really exist in
naive time.  There's _inherent_ tension between the naive time model
and the way multi-offset time zones actually behave.  So it goes.


>> It is true that the earlier and later of an ambiguous time in a fold
>> will compare equal in their own zone, but compare not equal after
>> conversion to UTC (or to any other zone in which they're not in one of
>> the latter zone's folds).  Is that what you're talking about?

> Yes. Or two different ambiguous times, where the properly earlier one
> compares greater and vice versa. I have no idea why anyone thinks this
> is reasonable or desirable behavior.

>From which I can guess, without asking, that you think "naive time"
itself is unreasonable and undesirable ;-)