On 08/17/2015 09:58 AM, Chris Barker wrote:
I know I really don't like the idea of delegating everything to the tzinfo object, it simply doesn't seem to be the right place for things other than, timezone info / operations.
The way I look at it is the final object is a merging of a datetime and tzinfo. The actual logic of how to add/subtract, etc., is built in to the datetime itself and the switch is built into the tzinfo -- so classic tzinfo (aka no switch present) gets the current behavior, while the new "strict" tzinfo (with switch present) would instigate the other behavior.
Off the cuff I would say have the datetime object check for certain methods in the tzinfo (such as add_datetime, add_timedelta, etc), and if present use them, otherwise use the normal methods. If performance becomes an issue we could have a different base class for strict datetimes, and the act of adding a tzinfo can change the class of the resulting datetime object to that strict subclass. -- ~Ethan~ _______________________________________________ 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/
