On 15-04-08, Lennart Regebro wrote:
> === Stdlib option 2: A datetime _is_dst flag ===
> 
> By having a flag on the datetime instance that says "this is in DST or not"
> the timezone implementation can be kept simpler.

Storing the offset itself instead of a flag makes things conceptually cleaner. 
You get a representation that's slightly harder to construct from the sorts of 
information you have lying around (tz name, naive datetime, is_dst flag) but is 
no harder to construct *and* validate, and then is easier to work with and 
harder to misuse. As an added bonus, you get a representation that's still 
meaningful when time changes happen for political rather than DST reasons.

Pros:
- tzinfo.utcoffset() and local->UTC conversions don't require zoneinfo access.
- it's harder to represent "I know this time is DST but I don't know what tz 
it's in" [I put this in pro because I don't see how this kind of ambiguity can 
lead to anything but trouble, but ymmv]
- this representation is meaningful regardless of whether a time zone has DST
- this representation meaningfully disambiguates across time changes not 
resulting from DST
Cons:
- tzinfo.dst() requires zoneinfo access
- tzinfo.tzname() requires zoneinfo access IF you want those horrible ambiguous 
abbreviations (is CST America/Chicago or America/Havana?) [I really wanted to 
put this in pro]
- (datetime, offset, tz) triples require validation [but so do (datetime, 
is_dst, tz) triples, even though it's easy to pretend they don't]
- constructing an aware datetime from a naive one, an is_dst flag, and a time 
zone requires zoneinfo access [but this is needed for the validation step 
anyway]

On 15-04-08, Alexander Belopolsky wrote:
> With datetime, we also have a problem that POSIX APIs don't have to deal 
> with: local time
> arithmetics. What is t + timedelta(1) when t falls on the day before DST 
> change? How would
> you set the isdst flag in the result?

It's whatever time comes 60*60*24 seconds after t in the same time zone, 
because the timedelta class isn't expressive enough to represent anything but 
absolute time differences (nor should it be, IMO). But it might make sense to 
import dateutil.relativedelta or mxDateTime.RelativeDateTime into the stdlib to 
make relative time differences (same local time on the next day, for instance) 
possible.

ijs
_______________________________________________
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Reply via email to