Path: csiph.com!goblin2!goblin.stu.neva.ru!newsfeed.xs4all.nl!newsfeed7.news.xs4all.nl!nzpost1.xs4all.net!not-for-mail
From: Random832 <random832@fastmail.com>
To: Tim Peters <tim.peters@gmail.com>
Cc: "Python-List" <python-list@python.org>, "datetime-sig" <datetime-sig@python.org>
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Type: text/plain
Subject: Re: [Datetime-SIG] Are there any "correct" implementations of tzinfo?
Date: Mon, 14 Sep 2015 15:58:34 -0400
In-Reply-To: <CAExdVN=s_V_uz9mSOtp6b6+fKjqLZHArXKUQ-ty5EYkLM5V2qw@mail.gmail.com>
References: <m2h9mzqyy7.fsf@fastmail.com> <CAExdVNm0rrxhbSONfQdor7e=9t+6Tg3hh6eFq-h0NnfdpteVYg@mail.gmail.com> <1442085362.324875.381920729.5E7A6DCE@webmail.messagingengine.com> <CAExdVNnUwRKN2q=trpnD9=mxnXvuosWKO+s5=PCfjAO45-Yugw@mail.gmail.com> <CAP7h-xYFAggqbJBNCZbYFwUqCPzW7-4Rc0x_SzgAumpFYAr6oA@mail.gmail.com> <CAExdVNmfTsqunRR_b-Q1YqWrTjsV1L5ppAoAnL7SUwgR2PFU0A@mail.gmail.com> <CAP7h-xbqq2Eu+vVO2g4WmbRJ=gmL1r9D2sWhKe=qQ8Ev-n415w@mail.gmail.com> <CAP7+vJ+1Vg21qOWAD+9R2REDnWiW4o6nj=Rh8fx3x3cAZipcdw@mail.gmail.com> <CAP7h-xbA6ZagKj+rQ_cCc8d0oK1F329AAhSjY240iiDyB4756A@mail.gmail.com> <CAExdVNnw6zfJQ_wFOurjj6kcLcbr9RgXA7kvyNPmgraMcHU4vQ@mail.gmail.com> <CAP7h-xYp=MsOcvFXNCHNkXDDGH=jcAwYSSw1WWchy5bwZKjwLA@mail.gmail.com> <201509131224.t8DCOXHO004891@fido.openend.se> <CAExdVNkN465=bWeY61PFAxpiUQ-u0p2zaqtwH8PQWyQO4Jw9Mg@mail.gmail.com> <201509131600.t8DG07e0025688@fido.openend.se> <CAExdVNm3e43mJ3tqcUc9175WssV4zeuO024svJbMTjrTab=Qew@mail.gmail.com> <201509132031.t8DKVTwJ028027@fido.openend.se> <CAExdVNkeRVgV8CXLugMgqhUSuXU=qHYSFUo24Xw83X=8tVBjCg@mail.gmail.com> <201509140827.t8E8RPqb001076@fido.openend.se> <CAExdVNn2wM8YW=Jg=aM86X6RaaVYPTioTSJ2d1gGp0k76CN3mg@mail.gmail.com> <1442257996.253100.383441705.7A0986C7@webmail.messagingengine.com> <CAExdVN=s_V_uz9mSOtp6b6+fKjqLZHArXKUQ-ty5EYkLM5V2qw@mail.gmail.com>
Precedence: list
Newsgroups: comp.lang.python
Message-ID: <mailman.560.1442260723.8327.python-list@python.org>
Lines: 45
NNTP-Posting-Host: 2001:888:2000:d::a6
Xref: csiph.com comp.lang.python:96597

On Mon, Sep 14, 2015, at 15:30, Tim Peters wrote:
> You're assuming much more than POSIX - and the ISO C standard -
> requirs.  My description was quite explicitly about how POSIX has done
> it all along.  tm_gmtoff and tm_zone are extensions to the standards,
> introduced (IIRC) by BSD.  Portable code (including Python's
> implementation) can't assume they're available.

No, but that doesn't mean it's not in fact true (what was under
discussion was "your own machine", not "a minimal POSIX
implementation"). And it doesn't mean it's not a best practice that
python can and should copy. I'm not talking about *using* it, I'm
talking about working the same way independently, so this has nothing to
do with assuming it's available.

> It was off the table because, for backward compatibility, we need to
> mess with the pickle format as little as possible.  It's vital that
> datetimes obtained from old pickles continue to work fine, and that
> pickles obtained from new datetime objects work fine when loaded by
> older Pythons unless they actually require the new fold=1 possibility.

I don't see how this would prevent that. Aware datetimes have a tzinfo
*right there* that can be asked for a value to populate utcoffset with
if there isn't a pickled one.

> > (No, I don't *care* how that's not how it's defined,
> 
> ?  How what is defined?:

Just trying, unsuccessfully apparently, to head off the "no, it's
defined as working the same as a naive datetime if the tzinfo values are
the same" argument that got brought up the *last* time I made this
claim.

> > it is *in fact* true for the UTC value that you will ever actually get
> > from converting the values to UTC *today*, and it's the only total
> > ordering that actually makes any sense)
> 
> 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. The sort order today is equivalent
to using that value in all cases unless you've got a pathological tzinfo
specifically crafted to break it. I think that's an important enough
invariant to be worth keeping, since it is the only possible way to
provide a total order in the presence of interzone comparisons.