<div dir="ltr"><div><div><div><div><div><div>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.<br><br></div>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):<br><br></div><div>- I'm surprised the name of the proposed flag doesn't occur in the abstract.<br></div><div><br></div><div>- 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).<br></div><div><br></div>- The sidebar doesn't show up as a sidebar, but as somewhat mysterious text, on <a href="https://www.python.org/dev/peps/pep-0495/">https://www.python.org/dev/peps/pep-0495/</a> (it does on <a href="http://legacy.python.org">legacy.python.org</a>, 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.)<br><br></div>- Conversely, on <a href="http://legacy.python.org">legacy.python.org</a> there are some error messages about "Unknown directive type "code"" (lines 112, 118).<br><br></div><div>- "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".<br></div><div><br>- 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?<br><br>- 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.<br><br>- "[1] An instance that has
        <tt class="docutils literal">
         first=False
        </tt>
        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?<br><br></div></div>-  "In CPython, a non-boolean value of
      <tt class="docutils literal">
       first
      </tt>
      will
raise a
      <tt class="docutils literal">
       TypeError
      </tt>
      , but other implementations may allow the value
      <tt class="docutils literal">
       None
      </tt>
      to behave the same as when
      <tt class="docutils literal">
       first
      </tt>
      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?<br><br></div><div>- 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(). :-(<br><br>- "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.<br><br>- "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.)<br><br>- "... 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.)<br></div><div><br>- "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.<br><br></div>- 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.<br><div><br>- "[2] As of Python 3.5,
        <tt class="docutils literal">
         tzinfo
        </tt>
        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.)<br></div><div><br>- "This proposal will have little effect on the programs that do not read
the
     <tt class="docutils literal">
      first
     </tt>
     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.<br><br></div><div>- 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?<br><br></div><div>- 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?<br></div><div><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Sun, Aug 16, 2015 at 3:49 AM, Alexander Belopolsky <span dir="ltr"><<a href="mailto:alexander.belopolsky@gmail.com" target="_blank">alexander.belopolsky@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">PEP 495 [1] is a deliberately minimalistic proposal to remove an<br>
ambiguity in representing some local times as datetime.datetime<br>
objects.<br>
<br>
The concept has been extensively discussed on python-ideas and this<br>
mailing list.  I believe a consensus has been reached and it is<br>
reflected in the PEP.<br>
<br>
PEP 495 does not propose any changes to datetime/timedelta<br>
arithmetics, but it has been agreed that it is a necessary step for<br>
implementing the "strict" rules.<br>
<br>
[1]: <a href="https://www.python.org/dev/peps/pep-0495" rel="noreferrer" target="_blank">https://www.python.org/dev/peps/pep-0495</a><br>
_______________________________________________<br>
Datetime-SIG mailing list<br>
<a href="mailto:Datetime-SIG@python.org">Datetime-SIG@python.org</a><br>
<a href="https://mail.python.org/mailman/listinfo/datetime-sig" rel="noreferrer" target="_blank">https://mail.python.org/mailman/listinfo/datetime-sig</a><br>
The PSF Code of Conduct applies to this mailing list: <a href="https://www.python.org/psf/codeofconduct/" rel="noreferrer" target="_blank">https://www.python.org/psf/codeofconduct/</a><br>
</blockquote></div><br><br clear="all"><br>-- <br><div class="gmail_signature">--Guido van Rossum (<a href="http://python.org/~guido" target="_blank">python.org/~guido</a>)</div>
</div>