Re: [Datetime-SIG] Calendar vs timespan calculations...
On Thu, Jul 30, 2015 at 6:31 PM, Tim Peters
[Guido]
... The road to improvement that I encourage everyone to explore: add an is_dst flag (with a different name)
There is no path whatsoever to "correct in all cases" in its absence, so this should be the top priority for those to whom "correct in all cases" is their top priority.
And that's why I listed it first. :)
and create new timedelta-ish classes that implement "human" arithmetic (similar to what pytz offers)
This part seems confused to me: beyond wrapping zoneinfo in a pile of tzinfo objects, pytz's secondary thrust appears to be "correct in all cases" involving DST transition times. Doing things like allowing to correctly distinguish between the ambiguous times when DST ends is, if I understand anything of your intent, a case of better implementing "strict time" than of implementing "human time". IOW, to the extent arithmetic in pytz acts like "human time", it inherits that behavior from what Python already does.
Oops, I should have checked my facts. I misremembered what pytz does. Indeed "human time" is not one of its features.
and "strict" arithmetic (similar to [NJ]odaTime, IIUC).
That sounds right.
Separately, standardized access in the stdlib to a tz database (see another thread).
That's pytz's primary thrust. Also part of dateutil's thrust (dateutil leaves Python's arithmetic results entirely alone in all cases, but also supplies many "calendar operations" useful regardless of whether you use _its_ wrapping of zoneinfo and/or Windows registry databases).
Aha! I'd forgotten about dateutil -- it claims "computing of relative deltas (next month, next year, next monday, last week of month, etc)" which sounds more like my "human time" (at least the "next month, next year" part).
[1] The *implementation* may change, but not in a way that changes observable behavior, except for the addition of new attributes, parameters and/or methods.
I'm afraid that may not be entirely possible. For example, if datetime objects grow a new attribute, (like some spelling of .is_dst) then repr() presumably needs to display it. But I know what you mean ;-)
;-) -- --Guido van Rossum (python.org/~guido)
participants (1)
-
Guido van Rossum