[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 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. > 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). > [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 ;-) _______________________________________________ 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/
