[Python-Dev] Status on PEP-431 Timezones

[Isaac Schwabacher]

On 15-04-08, Alexander Belopolsky  wrote:
> 
> On Wed, Apr 8, 2015 at 3:57 PM, Isaac Schwabacher <ischwabacher at wisc.edu <ischwabacher at 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 sametimekeeping 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.

I'm viewing a time zone as a map from UTC to local time; for example, America/Chicago is a time zone. I'm not proposing storing the offset as an alternative to storing the *time zone*, I'm proposing it as an alternative to storing whether a given time is DST or not. We really don't care whether a time is DST or not; we care about the local time and the offset, and we need the time zone because otherwise we can't relate our time to other times. So our times would look like "2013-11-03 01:30:00-0500 America/Chicago" and an hour later, "2013-11-03 01:30:00-0600 America/Chicago". And all of that information is stored in the datetime object.

> ..
> > 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)

The current definition of datetime.timedelta doesn't allow any reasonable definition of
datetime(2013, 11, 3, 23, 30, tz=zoneinfo('America/Chicago')) - datetime(2013, 11, 3, 0, 30, tz=zoneinfo('America/Chicago'))
other than timedelta(1) because the seconds field is not allowed to be more than 60*60*24.

ijs