[Datetime-SIG] Adding PEP 495 support to dateutil

[Guido van Rossum]

On Fri, Sep 18, 2015 at 10:05 AM, Paul Ganssle <paul at ganssle.io> wrote:

> On 9/18/2015 11:56, Tim Peters wrote:
>
> 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.
>
> 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.
>
> 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.
>
> 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.
>

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?


> 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 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.
>
>
> 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).
>
>
> 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, these tests
> <https://github.com/dateutil/dateutil/pull/127/files#diff-f4452d36e9493b89cd3b961d71465007R5771>
> 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 fold left the old behavior intact.
>
> 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.
>
> 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.
>
> 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).
>
> 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 *interface* across various
> platforms.
>
> As for the question of whether to preserve the "wrong" values for the sake
> of backwards compatibility, I'm not likely to sacrifice maximum *accuracy*
> across platforms for maximum *consistency* across platforms. But again,
> this is somewhat off-topic.
>
> _______________________________________________
> Datetime-SIG mailing list
> Datetime-SIG at python.org
> https://mail.python.org/mailman/listinfo/datetime-sig
> The PSF Code of Conduct applies to this mailing list:
> https://www.python.org/psf/codeofconduct/
>



-- 
--Guido van Rossum (python.org/~guido)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/datetime-sig/attachments/20150918/e6a0ac33/attachment.html>