[Datetime-SIG] Adding PEP 495 support to dateutil

[Paul Ganssle]

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.

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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/datetime-sig/attachments/20150918/113ed65b/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/113ed65b/attachment-0001.sig>