<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Fri, Sep 18, 2015 at 10:05 AM, Paul Ganssle <span dir="ltr"><<a href="mailto:paul@ganssle.io" target="_blank">paul@ganssle.io</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div bgcolor="#FFFFFF" text="#000000"><span class="">
On 9/18/2015 11:56, Tim Peters wrote:<br>
<blockquote type="cite">
Because dateutil inherits the default .fromutc(), it's all but
certain
it can't handle cases in the IANA database where a zone's base
("standard") offset changed either.<br>
<br>
But it's handling gaps & folds due to DST transitions as well
as is
_possible_ for a hybrid tzinfo given datetime's original design.
There was no provision in datetime to make it possible for a
hybrid
tzinfo to know whether the earlier or later of an ambiguous local
time
is intended. That's not dateutil's fault, and not something any
hybrid tzinfo can solve before PEP 495 is implemented.<br>
<br>
dateutil is following the doc's advice to consider an ambiguous
time
to be the later (in "standard time"), which in combination with
inheriting the default .fromutc() is enough to ensure that
UTC->local
conversion at least mimics the hands on the local clock (skipping
local times at DST start, and repeating some at DST end). So it's
doing the best it _can_ do now in those respects.
</blockquote></span>
This is quite possibly true, and is roughly in line with my thinking
on the matter to date, but in my mind the behavior of dateutil with
respect to ambiguous times is undefined, so I'm not going to add
tests that enforce an arbitrary implementation choice as it's not
behavior I want to lock down.<br></div></blockquote><div><br></div><div>Could you at least lock down that ambiguous times return *something* rather than raising an exception? Or perhaps even that they return one of two valid alternatives?<br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div bgcolor="#FFFFFF" text="#000000">
It's a separate question as to whether it can or cannot do better in
some cases. The issues I linked to are both cases where an
unambiguously specified time ("now" or a time specified in UTC with
an IANA time zone) are incorrectly converted into local time. It is<i>
</i>almost certainly true that enough information is available to
properly localize these datetimes, but at least in the case of
localizing "now" the cost in doing so is additional complexity on
the back-end.<span class=""><br>
<br>
<blockquote type="cite"><br>
<pre>The goal of PEP 495 is to make it possible for hybrid tzinfos to
handle all cases of gaps and folds due to any cause whatsoever
(provided that folds are never worse than 2-to-1), What Alex is
really after here is to kick the tires on PEP 495, to make sure:
1. All cases in the IANA database are in fact solved (that database
is the richest source of the goofiest zone changes to date).
2. That it's not only possible, but implementable with reasonable effort
and performance.
dateutil was "the obvious" base to start from, since it's the only
widely used wrapping of the IANA database using hybrid tzinfos (pytz
took a very different path).
</pre>
</blockquote>
<br></span>
Yes, this was more or less my understanding. I just thought I'd put
it out there in case the fact that the more complex nature of the
actual implementation had some bearing on the thinking about the
implementation. For example, <a href="https://github.com/dateutil/dateutil/pull/127/files#diff-f4452d36e9493b89cd3b961d71465007R5771" target="_blank">these
tests</a> could be problematic from a backwards compatibility
standpoint. I haven't had time to read the PEP or the discussion on
the matter, so maybe this has already been considered, but would
make for a simpler interface if an unspecified value for <tt>fold</tt>
left the old behavior intact.<br>
<br>
I'll definitely read these things when I have time, so if it's
already been discussed no need to re-hash on my behalf.<span class=""><br>
<br>
<blockquote type="cite">
<pre>Whether dateutil can make _use_ of this experiment is up to you ;-)
In cases where results differ from the current implementation, the
latter results can only be called "wrong". Which you may well need to
preserve.
</pre>
</blockquote>
<blockquote type="cite">
<pre>In which case, I'd suggest leaving the current implementation alone,
and _adding_ a new wrapping of tzfiles based on Alex's code.
dateutil's get-a-zone factory functions would need to grow some way to
spell "I want a pre-495 tzinfo" or "I want a post-495 tzinfo". New
functions, optional function flags, global setting ... whatever you
think works best.
Of course this would apply to wrappings of other sources of zone info
too, but the IANA database must be by far the hardest (e.g., fold and
gap times can be deduced directly from a POSIX TZ string rule, which
are only subject to twice-a-year DST changes at worst).
</pre>
</blockquote></span>
I think it's likely premature (and the wrong forum) to discuss such
downstream implementation details, but I imagine that it won't be
difficult to devise some scheme that by default gives the right
answer where possible, as long as there's a relatively
straightforward way of wrapping datetimes such that it provides a
consistent <i>interface</i> across various platforms.<br>
<br>
As for the question of whether to preserve the "wrong" values for
the sake of backwards compatibility, I'm not likely to sacrifice
maximum <i>accuracy</i> across platforms for maximum <i>consistency</i>
across platforms. But again, this is somewhat off-topic.<br>
</div>
<br>_______________________________________________<br>
Datetime-SIG mailing list<br>
<a href="mailto:Datetime-SIG@python.org">Datetime-SIG@python.org</a><br>
<a href="https://mail.python.org/mailman/listinfo/datetime-sig" rel="noreferrer" target="_blank">https://mail.python.org/mailman/listinfo/datetime-sig</a><br>
The PSF Code of Conduct applies to this mailing list: <a href="https://www.python.org/psf/codeofconduct/" rel="noreferrer" target="_blank">https://www.python.org/psf/codeofconduct/</a><br></blockquote></div><br><br clear="all"><br>-- <br><div class="gmail_signature">--Guido van Rossum (<a href="http://python.org/~guido" target="_blank">python.org/~guido</a>)</div>
</div></div>