[Datetime-SIG] PEP 495 (Local Time Disambiguation) is ready for pronouncement

Sun Aug 16 21:23:59 CEST 2015

I think that a courtesy message to python-dev is appropriate, with a link
to the PEP and an invitation to discuss its merits on datetime-sig.

Here are my thoughts about the PEP so far, and some nits about the text
(sorry for hopping around in the text a bit, I tried to sort my bullets but
I reviewed the PEP skipping back and forth a lot, so this reflects that):

- I'm surprised the name of the proposed flag doesn't occur in the abstract.

- The rationale might explicitly mention the two cases we're thinking
about: DST transitions and adjustments to the timezone's base offset --
noting that the latter may be an arbitrary interval (not just an hour).

- The sidebar doesn't show up as a sidebar, but as somewhat mysterious
text, on https://www.python.org/dev/peps/pep-0495/ (it does on
legacy.python.org, but we're trying to avoid that site). Maybe you should
file a bug with the pydotorg project on GitHub (if you haven't already).
(While I like the artwork, it's a bit un-PEP-like, and maybe not worth it
given the problems making the image appear properly.)

- Conversely, on legacy.python.org there are some error messages about
"Unknown directive type "code"" (lines 112, 118).

- "a fold is created in the fabric of time" sounds a bit like
science-fiction. I'd just say "a time fold is created", or "a fold is
created in time".

- Despite having read the section about the naming, I'm still not wild
about the name 'first'. This is in part because this requires True as the
default, in part because without knowing the background its meaning
somewhat mysterious. I'm not wild about the alternatives either, so perhaps
this requires more bikeshedding. :-( (FWIW I agree that the name should not
reference DST, since time folds may appear for other reasons.) Hmm... Maybe
"fold=True" to select the second occurrance?

- I'm a bit surprised that this flag doesn't have three values (e.g. None,
True, False) -- in C, the tm_isdst flag in struct tm can be -1, 0 and 1,
where -1 means "figure it out" or "don't care". The "don't care" case
should allow stricter backward compatibility.

- "[1] An instance that has first=False in a non-ambiguous case is said to
represent an invalid time ..." Could you quickly elaborate here whether
such an invalid time is considered an hour later than the valid
corresponding time with first=True, given a reasonable timezone with and
without DST?

- "In CPython, a non-boolean value of first will raise a TypeError , but
other implementations may allow the value None to behave the same as when first
is not given." This is surprisingly lenient. Why allow the second behavior
at all? (Surely all Python implementations can distinguish between a value
equal to None and a missing value, even if some kind of hack is needed.)
Also, why this clause for replace() but not for other methods?

- I'm disappointed that there are now some APIs that explicitly treat a
naive datetime as local (using the system timezone). I carefully avoided
such interpretation in the original design, since a naive datetime can also
be used to represent a point in UTC, or in some timezone that's implicit.
But I guess this cat is out of the bag since it's already assumed by
timestamp() and fromtimestamp(). :-(

- "Conversion from POSIX seconds from EPOCH" I'd move this section before
the opposite clause, since it is simpler and the other clause references
fromtimestamp(). The behavior of fromtimestamp() may also be considered
motivational for having only the values True and False for the flag.

- "New guidelines will be published for implementing concrete timezones
with variable UTC offset." Where? (Is this just a forward reference to the
next section? Then I'd drop it.)

- "... must follow these guidelines." Here "must" is very strong (it is the
strongest word in "standards speak", stronger than "should", "ought to",
"may"). I recommend "should", that's strong enough. Also, doesn't this
apply to all tzinfo subclasses except fixed-offset ones? That would mean
that any current tzinfo subclass is deemed non-compliant with this PEP.
That feels too strong. Your use of "new subclasses" also suggests that this
doesn't apply to existing subclasses, but that's not enough -- I think it
should be reasonable for someone writing a tzinfo subclass to continue to
ignore the "first" flag, and still be considered a valid tzinfo subclass,
if they don't care about what happens in time folds. (Note that I have
nothing against the guidelines themselves -- just against the implication
that not following them makes a class in some way "non-compliant", which is
a pretty strong damnation in standards speak.)

- "We chose the minute byte to store the the "first" bit because this
choice preserves the natural ordering." This only works with folds of
exactly one hour. Also, is the natural ordering (of the pickles,
apparently) used anywhere? I would hope not. Finally, given that two times
that differ only in their 'first' flag compare equal, the natural ordering
(if relevant :-) would be to store/compare the 'first' bit last.

- Temporal Arithmetic (probably shouldn't have an "s" at the end): this
probably needs some motivation. I think it's inevitable (since we don't
know the size of the time fold), but it still feels weird.

- "[2] As of Python 3.5, tzinfo is ignored whenever timedelta is added or
subtracted ..." I don't see a reason for this footnoote to discuss possible
future changes to datetime arithmetic; leave that up to the respective PEP.
(OTOH you may have a specific follow-up PEP in mind, and it may be better
to review this one in the light of the follow-up PEP.)

- "This proposal will have little effect on the programs that do not read
the first flag explicitly or use tzinfo implementations that do." This
seems ambiguous -- if I use a tzinfo implementation that reads the first
flag, am I affected or not? Also, "the programs" should be just "programs",
and I'm kind of curious why the hedging of "little effect" (rather than "no
effect") is needed. Also, you might give some examples of changes that
programs that *do* use the first flag may experience.

- In a reply to this thread, you wrote "The rule for the missing time is
the opposite to that for the ambiguous time. This allows a program that
probes the TZ database by calling timestamp with two different values of
the "first" flag to avoid any additional calls to differentiate between the
gap and the fold." Can you clarify this (I'm not sure how this works,
though I intuitively agree that the two rules should be each other's
opposite) and add it to the PEP?

- Would there be any merit in proposing, together with the idea of a
three-value flag, that datetime arithmetic should use "timeline arithmetic"
if the flag is defined and a tzinfo is present?

On Sun, Aug 16, 2015 at 3:49 AM, Alexander Belopolsky <
alexander.belopolsky at gmail.com> wrote:

> PEP 495 [1] is a deliberately minimalistic proposal to remove an
> ambiguity in representing some local times as datetime.datetime
> objects.
>
> The concept has been extensively discussed on python-ideas and this
> mailing list.  I believe a consensus has been reached and it is
> reflected in the PEP.
>
> PEP 495 does not propose any changes to datetime/timedelta
> arithmetics, but it has been agreed that it is a necessary step for
> implementing the "strict" rules.
>
> [1]: https://www.python.org/dev/peps/pep-0495
> _______________________________________________
> 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/20150816/d6d8de71/attachment-0001.html>