On Mon, Aug 31, 2015 at 2:38 PM, Carl Meyer wrote: [Tim Peters]

...

Nope. There's nothing here about, e.g., messing with datetime constructors, .replace(), .combine() ... "naive time" is left alone here. It's only timezone-specific operations targeted here, which are all implemented _by_ tzinfo objects. Not by datetime itself.

There wasn't any of that stuff (messing with constructors, or replace, or combine, or naive time) in what Alex and I were discussing in the other thread, either. Just the idea of having `utcoffset()` raise an error if it hit an ambiguity.

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!