On Tue, Jun 5, 2012 at 7:44 PM, Nick Coghlan <ncoghlan at gmail.com> wrote: > On Wed, Jun 6, 2012 at 11:57 AM, Alexander Belopolsky > <alexander.belopolsky at gmail.com> wrote: >> On Tue, Jun 5, 2012 at 7:11 PM, Greg Ewing <greg.ewing at canterbury.ac.nz> wrote: >>> What would be so bad about giving datetime objects >>> a DST flag? Apps that don't care could ignore it and >>> get results no worse than the status quo. >> >> This would neatly solve the round-trip problem, but will open a >> different can of worms: what happens to the dst flag when you add a >> timedelta? If dst flag is optional, should you be able to compare >> dst-aware and dst-naive instances? > > Yeah, I think it's cleaner to lean on tzinfo as much as possible. If > we decide we need to support both "local, treating the overlapping > hour as standard time" and "local, treating the overlapping hour as > DST", then that could be represented as two different timezone objects > and follow the normal rules for reconciling timezones rather than > adding a new flag anywhere. Let's not add a DST flag to datetime objects. -- --Guido van Rossum (python.org/~guido)
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4