<div dir="ltr"><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Aug 31, 2015 at 2:38 PM, Carl Meyer <span dir="ltr"><<a href="mailto:carl@oddbird.net" target="_blank">carl@oddbird.net</a>></span> wrote:</div><div class="gmail_quote">[<span style="color:rgb(80,0,80);font-size:12.8000001907349px">Tim Peters]</span><br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><span class="">> Nope.  There's nothing here about, e.g., messing with datetime<br>
> constructors, .replace(), .combine() ... "naive time" is left alone<br>
> here.  It's only timezone-specific operations targeted here, which are<br>
> all implemented _by_ tzinfo objects.  Not by datetime itself.<br>
<br>
</span>There wasn't any of that stuff (messing with constructors, or replace,<br>
or combine, or naive time) in what Alex and I were discussing in the<br>
other thread, either. Just the idea of having `utcoffset()` raise an<br>
error if it hit an ambiguity.</blockquote></div><br>I think the main difference between Tim's current proposal and what was previously discussed is that all older proposals somehow required  a third value for fold.   Note that there is a third variant suggested by Guido off-list and discussed in the PEP:  have fold=-1 by default, ignore it unless it is nonnegative and design whatever you want for fold=0/1 without concerns for backward compatibility.   This effectively will give two different datetime classes: classic and new.  Both are perfectly consistent, but if you think interoperation between naive and aware is confusing, try to explain how new naive instances will interoperate with classic aware!</div></div>