[Tim]

...

At a high level, I'm questioning the "_never_ raise an exception" PEP 495 behavior. It grates. "Errors should never pass silently" and such.

[Alex][

But these are not errors!

That depends on the application. As W Kahan quipped when devising the IEEE-754 exception model, they're called "exceptions" because _whatever_ you do someone will take exception to it ;-)

As I mentioned before, it was bad PR on my part to call datetimes in the gaps or with ignorable fold=1 "invalid." I should have called them "denormalized."

It doesn't matter what they're called _except_ for "PR purposes". I'm not trying to do PR here.

I believe many aware datetime manipulation algorithms can benefit from having denormalized instances as intermediate values and being able to call .utcoffset() and friends on such instances.

That's why, e.g., C's mktime allows "insane" values for the day, etc. Python's internal C datetime implementation does too. It's also why Paul Eggert patched glibc's mktime to "pick one" for a gap case.. But that's all C, working at a level so low everything is painful. datetime isn't intended to be infinitely painful ;-)

My primary use case is the "naive scheduler" which gives you no means to schedule anything with fold=1 and if you give it 02:45 AM in the gap it will silently take it for 03:45 AM. As long as it displays the correct time in every reminder, I don't care that it did to chastise me for not knowing about the DST gap.

I don't dispute that, in a gap case, picking the time that "would have displayed" had the user moved the clock forward is most useful most often. If that's believed to be overwhelmingly the case, that at least argues for opt-in exceptions. But passing fold=1 in a non-fold/gap case is almost certainly a flat-out programmer error, _except_ that PEP 495 requires never ever complaining about it, and to the contrary _requires_ it to be done if the user wants to find out whether their datetime is any way odd. C'mon, admit it - _part_ of it makes you cringe too, if even just a little ;-)