[Datetime-SIG] Another round on error-checking

[Alexander Belopolsky]

On Thu, Sep 3, 2015 at 6:59 AM, Carl Meyer <carl at oddbird.net> wrote:

> But then it can't quite
> decide how to rationalize that new bit of information with its naive
> internal view of time, so it settles on a mish-mash of inconsistent
> behavior that violates basic arithmetic identities we all learned in
> elementary school and only makes any sense if you've followed this
> entire thread.
>

It is actually easier to understand if you *don't* read this thread because
some of the earlier posts (including my own) are quite confusing.  The rule
we settled on is quite simple and consistent with the status quo.   First,
you need to realize that aware fold=1 times *can* be represented in the
current version of datetime, but you must use a different tzinfo for that.
  Popular choices are timezone.utc or the fictitious fixed offset standard
time zone.  (I call these zones fictitious because they represent a
possibly non-existing time zone which does not observe DST changes.)

For example, in US/Eastern, if you want to represent [01:30/fold=1], you
can either use [01:30/tzinfo=EST] or [06:30/tzinfo=UTC] which conveniently
compare as equal.  What 495 gives you is the third way to spell the same
time: [01:30/fold=1,tzinfo=Eastern].  It is quite natural that this third
spelling will have exactly the same properties as the first two:

[01:30/fold=0] < [01:59/fold=0] < [06:30/tzinfo=UTC] == [01:30/tzinfo=EST]
== [01:30/fold=1] < [02:00/fold=0]

The only "basic arithmetic identities" that are being violated here are the
ones that are already violated by aware datetimes.  For example (t1 - u) -
(t2 - u) is not equal to t1 - t2 if u is a tzinfo=UTC instance and t1 and
t2 are two tzinfo=Eastern instances on the different sides of the gap.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/datetime-sig/attachments/20150903/143cd772/attachment.html>