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. Cheers, Nick. -- Nick Coghlan | ncoghlan at gmail.com | Brisbane, Australia
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