[Datetime-SIG] PEP-431/495

[Carl Meyer]

On 08/24/2015 11:18 AM, Guido van Rossum wrote:
> I'm still unclear on why pytz solves two problems (timeline arithmetic
> and a tzinfo database). What is the linkage between the two besides that
> you (Stuart) feels that both are important problems to solve?

Didn't Stuart already answer this in his last email?

"Grump. I always interpreted that documentation to mean that timezone
conversions where *my* problem as the author of the tzinfo
implementation. I thought it was a documented problem to be fixed
if/when Python ever provided more complex tzinfo implementations, and
one of the reasons it never did provide such implementations in the
first place."

"Classic behaviour as you describe it is a bug. It sounds ok when you
state it as 'add one day to today and you get the same time tomorrow'.
It does not sound ok when you state it as 'add one second to now and
you will normally get now + 1 second, but sometimes you will get an
instant further in the future, and sometimes you will get an instant
in the past'."

In other words, he just assumed that timeline arithmetic was his only
reasonable option as the author of a useful, non-buggy tzinfo
implementation. As a user of pytz, it was certainly what I expected, and
I'd have considered "classic arithmetic" to be a bug (thanks to pytz, I
avoided even knowing that was Python's default behavior until this
thread), so I can't fault his assumption.

I think the other linkage between the two is that pytz's "every tzinfo
instance is fixed-offset" is the most natural way to solve the PEP-495
problem in the absence of PEP 495 and ensure that all datetime instances
are unambiguous and valid. Faced with "I need to store this extra
disambiguation bit in the tzinfo somehow, to clarify which of two
offsets is intended when a timezone transitions from one offset to
another", you can either store a boolean somewhere which is usually
irrelevant and very hard to name sensibly, or you can "store" the flag
by simply assigning a tzinfo instance which represents the specific
offset you want (but also knows its full timezone rules, so it can
"normalize" to a different offset when asked to).

Once you choose the latter implementation (which you might reasonably
choose even if you didn't care about arithmetic at all), Python gives
you timeline arithmetic automatically.

Carl

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL: <http://mail.python.org/pipermail/datetime-sig/attachments/20150824/240b3225/attachment.sig>