[Tim Peters]
>
> I think acceptance of 495 should be contingent upon
> someone first completing a fully functional (if not releasable)
> fold-aware zoneinfo wrapping.
[Alexander Belopolsky]
>
> I am making all development public early on and hope to see code reviews
and
On Sat, Sep 12, 2015 at 9:58 PM, Tim Peters wrote:
> I think acceptance of 495 should be contingent upon
> someone first completing a fully functional (if not releasable)
> fold-aware zoneinfo wrapping.
>
After studying both pytz and dateutil offerings, I decided that it is
easier to add "fold-a
On Mon, Sep 14, 2015 at 4:22 PM, Tim Peters wrote:
> > faster
> > than CPython can look up the .utcoffset method. (At least for times
> > within a few years around now.) A programmer who makes it slower should
> > be fired.
>
> So any programmer who implements .utcoffset() in Python should be
> f
On Mon, Sep 14, 2015 at 3:49 PM, Tim Peters wrote:
> It depends on how expensive .utcoffset()
> is, which in turn depends on how the tzinfo author implements it.
>
No, it does not. In most time zones, UTC offset in seconds can be computed
by C code as a 4-byte integer faster than CPython can lo
On Mon, Sep 14, 2015 at 3:44 PM, Random832 wrote:
> 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.
>
Sorry, this sentence does not parse. You are missing a "not" so
On Mon, Sep 14, 2015 at 4:08 PM, Random832 wrote:
> On Mon, Sep 14, 2015, at 15:48, Alexander Belopolsky wrote:
> > On Mon, Sep 14, 2015 at 3:44 PM, Random832
> > wrote:
> >
> > > It is an
> > > invariant that is true today, and therefore which you can&
On Mon, Sep 14, 2015 at 3:13 PM, Random832 wrote:
> (No, I don't
> *care* how that's not how it's defined, 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)
>
This
On Mon, Sep 14, 2015 at 3:30 PM, Tim Peters wrote:
> > make it much cheaper to maintain global invariants like a sort order
> > according to the UTC value
>
> It would be nice to have! .utcoffset() is an expensive operation
> as-is, and being able to rely on tm_gmtoff would make that dirt-cheap
On Sun, Sep 13, 2015 at 6:21 PM, Guido van Rossum wrote:
>
> Now, the question may remain how do people know what to set their
timezone to. But neither pytz nor datetime can help with that -- it is up
to the sysadmin.
Note that this question is also out of the scope of "tzdist", IETF Time
Zone D
On Sat, Sep 12, 2015 at 10:25 PM, Tim Peters wrote:
> > I will try to create a zoneinfo wrapping prototype as well, but I will
> > probably "cheat" and build it on top of pytz.
>
> It would be crazy not to ;-) Note that Stuart got to punt on "the
> hard part": .utcoffset(), since pytz only use
On Sat, Sep 12, 2015 at 6:24 PM, Guido van Rossum wrote:
> The repeated claims (by Alexander?) that astimezone() has the power of
> pytz's localize() need to stop.
Prove me wrong! :-)
> Those pytz methods work for any (pytz) timezone -- astimezone() with a
> default argument only works for th
On Sat, Sep 12, 2015 at 9:58 PM, Tim Peters wrote:
> > That's why I believe PEP 495 followed by the implementation
> > of fold-aware "as intended" tzinfos (either within stdlib or by third
> > parties) is the right approach.
>
> Me too - except I think acceptance of 495 should be contingent upon
On Sat, Sep 12, 2015 at 4:10 PM, Tim Peters wrote:
> "A potential problem" with .astimezone()'s default is that it _does_
> create a fixed-offset zone. It's not at all obvious that it should do
> so. First time I saw it, my initial _expectation_ was that it
> "obviously" created a hybrid tzinfo
On Sat, Sep 12, 2015 at 3:41 PM, Tim Peters wrote:
> > If there are not, maybe the intended semantics should go
> > by the wayside and be replaced by what pytz does.
>
> Changing anything about default arithmetic behavior is not a
> possibility. This has been beaten to death multiple times on th
14 matches
Mail list logo
