[Datetime-SIG] Another round on error-checking
carl at oddbird.net
Mon Aug 31 20:30:00 CEST 2015
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
AFAICT, you are re-proposing the same solution you characterized several
times earlier as "spraying errors all over the place" and "going nowhere
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 836 bytes
Desc: OpenPGP digital signature
More information about the Datetime-SIG