[Datetime-SIG] Another round on error-checking
carl at oddbird.net
Thu Sep 3 06:02:39 CEST 2015
On 09/02/2015 06:39 PM, Tim Peters wrote:
> We should be clearer about something up front: there are _two_
> notions of "backward compatibility" here:
> 1. After PEP 495 is implemented but before any 495-compliant tzinfos exist.
> 2. After PEP 495 is implemented and the user explicitly employs a
> 495-compliant tzinfo.
> There are few potential issues under #1, but - alas - not none, and -
> double alas - none of them would be altered by any kind of flag or
> inheritance pattern on tzinfos.
If the `fold` attribute is entirely ignored, in all cases, unless a
new-style tzinfo is present, then there are no issues under #1.
>> One reason to conflate with arithmetic is to limit the number of mental
>> models people have to comprehend. If we conflate, there would be two
>> models: "naive model" and "timeline model", and the choice between them
>> would be controlled by one flag.
>> I think that's already more than enough complexity for most people, but
>> it's simplicity itself compared to the possibility that we could end up
>> with three models: "naive model", "timeline model for conversions but
>> still naive for arithmetic", and "timeline model".
>> ISTM the second is too confusing and inconsistent in its view of the
>> world to be featured as a primary mode; if someone really needs it, it'd
>> be easy enough to write functions to do fast naive arithmetic on
>> strict-aware datetimes (strip the tzinfo, then add it back). (The
>> write-your-own-function argument can go both ways! ;)
> It was always intended that users who wanted timeline arithmetic work
> in UTC instead. Everyone agrees that's best practice for many
> reasons. "Even Stuart" ;-) will agree with the latter.
For apps doing heavy datetime arithmetic, I agree that working in UTC is
best (and that's what I do). It would also be reasonable to say that if
you want naive arithmetic with an implied timezone shared by all
instances, the best practice is to use naive datetimes and track the
implied timezone separately.
But given that we're not proposing to raise an exception on all
arithmetic with tz-annotated datetimes, it has to behave _somehow_, and
it should behave in the least-surprising and most-consistent way
possible. In a post-PEP-495 world, it is abundantly clear that
consistent timeline arithmetic would require fewer (that is, zero)
surprising violations of invariants.
If a new Python user is trying to calculate how long they slept when
they went to bed at 10pm on March 2 and got up at 6am on March 3, Python
should give them the right answer. Telling them "you should convert to
UTC first if you want your tz-aware datetime to actually be aware of the
tz transition" is going to sound a bit silly to them; they neither went
to sleep in UTC nor awoke in UTC; they did both in their own timezone.
> As to using functions, they're not symmetric situations: classic
> arithmetic is very fast, so fast that the overheads of calling a
> function and mucking around with stripping/reattaching tzinfos would
> be a major speed hit. timeline arithmetic is so slow that hardly
> matters. But work in UTC, as intended, and timeline arithmetic is the
> same thing as classic arithmetic, so is also very fast when performed
> the intended way.
Ok, continue using an old-style tzinfo (without the new `strict`
attribute) and you can continue to have fast classic arithmetic on
tz-annotated datetimes forever.
Or you can use a strict tzinfo and have tz-aware datetimes that
unambiguously represent a UTC-convertible instant.
But how many contortions and surprising behaviors is it worth to try to
provide both of those at once, in the same object?
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 836 bytes
Desc: OpenPGP digital signature
More information about the Datetime-SIG