[Datetime-SIG] Another round on error-checking

Carl Meyer carl at oddbird.net
Thu Sep 3 05:47:26 CEST 2015


[Tim]
> [Carl Meyer <carl at oddbird.net>]
>> ...
>> To summarize: trying to disambiguate folds leads to contradiction if the
>> implementation doesn't fully accept a "timeline" view of tz-aware
>> datetimes, because in a "naive" view, the two overlapping times in a
>> fold are the _same time_. The very idea of disambiguation itself is a
>> "timeline view" concept; it's not consistent with naive time.
> 
> Fun, isn't it?

If this is a fair summary, then why are we still trying to both keep a
"naive" model for aware datetimes and also disambiguate folds, when
we've just accepted that the two concepts are inherently contradictory
and combining them inevitably will lead to surprises?

If timezone-annotated datetimes in Python are really just supposed to
represent naive clock time with an associated timezone, then there is no
point in trying to disambiguate at a fold; both sides of the fold are
the same naive clock time in the same timezone.

If timezone-annotated datetimes in Python represent an unambiguously
UTC-convertible instant, then why shouldn't they consistently behave
that way (and happily eliminate all the surprising corner cases from PEP
495)?

If they are supposed to represent some quantum hybrid of the two, where
in some situations they behave like one and in some situations like the
other (that is the status quo, of course), is there a concisely-stated
consistent rule by which one can predict when they will behave like one
and when they will behave like the other? Will that rule still apply
post-PEP-495?

Carl

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: OpenPGP digital signature
URL: <http://mail.python.org/pipermail/datetime-sig/attachments/20150902/4e3db850/attachment.sig>


More information about the Datetime-SIG mailing list