[Datetime-SIG] Adding PEP 495 support to dateutil

Fri Sep 18 19:32:44 CEST 2015

This is a reasonable point that I'll have to mull over. I think by and
large I'd prefer to be agnostic about these sorts of things if they
don't have any bearing on my contribution to the interface. Everything
below datetime uses native python modules, so making explicit guarantees
about the results of what is essentially undefined behavior above and
beyond the guarantees the interpreter / standard is already making seems
unnecessary to me.

That said, I'll have to go over the module in more detail and see places
where the dateutil interface /should/ be making some guarantees about
the behavior.

On 9/18/2015 13:07, Guido van Rossum wrote:
> On Fri, Sep 18, 2015 at 10:05 AM, Paul Ganssle <paul at ganssle.io
> <mailto: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 <mailto: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 <http://python.org/%7Eguido>)

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/datetime-sig/attachments/20150918/ed479a1d/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 834 bytes
Desc: OpenPGP digital signature
URL: <http://mail.python.org/pipermail/datetime-sig/attachments/20150918/ed479a1d/attachment-0001.sig>