On Wed, Apr 8, 2015 at 3:57 PM, Isaac Schwabacher <ischwabacher@wisc.edu> wrote:
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.
It is important to distinguish two notions that unfortunately both called a "time zone." For lack of better terms, let me define "named offsets" and "locations" as follows: A "named offset" is an abbreviation such as UTC, EST, MSK, MSD which (at any given time) corresponds to a fixed offset from UTC. Since at different historical times, the same abbreviation such as MSK may correspond to a different offset, you cannot always derive one from another and extended struct tm provides fields for both: tm_gmtoff and tm_zone. A location is a name of geographical entity such as America/New_York which follows the same timekeeping rules. The isdst flag is necessary when you know the location and local time and want to find out the corresponding UTC time. In many locations, there is one our every year when knowing local time is not enough because the same local time corresponds to two different UTC times. This happens in the US when we move the clock back one hour some day in the Fall. UTC time marches on, but local time repeats the same hour. So in order to know what 01:30 AM is in New York, you also need to know whether it is before we moved the clocks back or after. So "storing the offset" and "storing a flag" are not two alternative solutions to the same problem- these are two solutions to two different problems. ..
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).
This is not what most uses expect. The expect datetime(y, m, d, 12, tzinfo=New_York) + timedelta(1) to be datetime(y, m, d+1, 12, tzinfo=New_York)