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
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Datetime-SIG mailing list [email protected] https://mail.python.org/mailman/listinfo/datetime-sig The PSF Code of Conduct applies to this mailing list: https://www.python.org/psf/codeofconduct/
