Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.python > #96603 > unrolled thread

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

Back to article view | Back to comp.lang.python

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: [Datetime-SIG] Are there any "correct" implementations of tzinfo? Random832 <random832@fastmail.com> - 2015-09-14 16:27 -0400

#96603 — Re: [Datetime-SIG] Are there any "correct" implementations of tzinfo?

On Mon, Sep 14, 2015, at 16:15, Tim Peters wrote:
> [Random832 <random832@fastmail.com>]
> 
> Whether or not datetimes stored  tm_gmtoff and tm_zone workalikes has
> no effect on semantics I can see.  If, in your view, they're purely an
> optimization, they're just a distraction for now.  If you're proposing
> to add them _instead_ of adding `fold`, no, that can't work, for the
> pickle compatibility reasons already explained.  Whether something is
> in a fold needs to preserved across pickling, but "almost all" pickles
> need to be readable by older Pythons too.  This is doable adding one
> bit, but not doable at all if we need to add arbitrary timedelta and
> string objects _instead_ of that bit.

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.

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

> >> Well, you lost me there.  In a post-495 world, conversion to UTC will
> >> work correctly in all cases.  It cannot today.;
> 
> > It'll provide *a* value in all cases.
> 
> It will provide the correct UTC offset in all cases.

I'm saying that *today*, even with no 495, it does provide *a* value in
all cases (even if that's sometimes the "wrong" value for an ambiguous
time). 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.

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

[toc] | [standalone]

Back to top | Article view | comp.lang.python

csiph-web