(original) (raw)
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
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).
..
> 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)