Hi Tim, On 08/31/2015 11:58 AM, Tim Peters wrote:

I've been playing with what it would take to wrap zoneinfo efficiently in a post-495 world. When I got to .utcoffset(), I just cringed when trying to implement the "in the face of ambiguity and/or impossibility, make stuff up ;-) ", parts.

The pytz folks have been enthusiastic about pytz's approach. Alas, it's a poor fit to datetime's design, because pytz strives to make it appear that "naive time" doesn't exist at all for datetimes with a tzinfo. But in the design, they do. Regardless of whether a tzinfo is present, a datetime is intended to be viewed as working in naive time. "Missing" and "ambiguous" times plain don't exist in naive time, so it's unnatural to check for them all over the place.

It's when a timezone-*specific* operation is attempted that the user is explicitly moving out of naive time (not merely when a tzinfo is attached). So, in my view, *that's* when to check. .utcoffset() is the primary such place (whether called directly or indirectly).

That's pretty much what I proposed in the first invalid-time-checking thread. Alex didn't like it because `utcoffset()` is called from so many different places: https://mail.python.org/pipermail/datetime-sig/2015-August/000499.html AFAICT, you are re-proposing the same solution you characterized several times earlier as "spraying errors all over the place" and "going nowhere fast." :-) Carl