On 06/06/2012 02:57, Alexander Belopolsky 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? > Here's my take on it: datetime objects would consist of the UTC time, time zone and DST. When comparing 2 datetime objects, it would compare the UTC times. The difference between 2 datetimes would be the difference between their UTC times. When converting to a string, you would specify whether you wanted local time (UTC + TZ + DST) or not. When converting from a string, it would assume UTC time unless the string gave the time zone and DST or you specified that it was local time. It would convert local time to UTC time and set the time zone and DST appropriately. After adding a timedelta to a datetime, it would normalise the DST according to the local rules.
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