[Python-Dev] Status on PEP-431 Timezones

[Isaac Schwabacher]

On 15-04-09, Alexander Belopolsky  wrote:
> 
> On Thu, Apr 9, 2015 at 11:59 AM, Isaac Schwabacher <ischwabacher at wisc.edu(javascript:main.compose()> wrote:
> 
> > > Storing isdst in the datetime object would allow utcoffset(dt) to distinguish between 1:30AM before clock change and 1:30AM after. Where do you propose to store the offset?
> > 
> > I propose to add an offset field to datetime.datetime. It should be set precisely when the tz field is set, and it should contain either a timedelta or an integer number of (possibly fractional) seconds, depending on what color the bikeshed gets painted. This is, IIUC, precisely where Lennart is proposing to store the is_dst flag.
> 
> Can you describe a situation where having isdst flag is not sufficient?
> 
> Note that in many applications you want to find the appropriate offset knowing only local time and location, so requiring users to supply the offset defeats the purpose of the time zone database. In many applications, the isdst flag can be hidden from the user. For example, a scheduling application can pretend that a repeated hour does not exist and always assume that 01:30 AM is the first 01:30 AM. (In many business applications, it is a good idea anyways.) Alternatively, a user attempting to schedule an event at an ambiguous time can be presented with a warning and a request to pick one of two possible times. This would be a much friendlier interface than the one always requiring the use to specify the UTC offset.

I'm suggesting an internal representation, not a user interface. The only user-facing consequence of this internal representation would be exposing the offset to datetime.replace() and as a field on the object. All of the other interfaces that convert naive datetimes into aware datetimes would still use the is_dst flag as specified in the PEP. The intention is to make it easy to implement arithmetic and things like relative timedeltas.

But looking at datetime.h, which seems to be willing to sacrifice conceptual simplicity in order to pack a datetime into as few bytes in memory as possible, it seems like whatever made that a good idea makes this a bad one. :/

> > if someone passed you datetime(2013, 11, 3, 1, 30) without a time zone. astimezone assumes that the input naive time is UTC, which is not the case here.
> 
> No, it does not. Please read the documentation: "self must be aware (self.tzinfo must not be None, and self.utcoffset() must not return None)."

Whoops, you're right. But that's even worse-- it doesn't give you a way to convert a naive datetime at all. Currently the only way from "2013-11-03 01:30:00" to "2013-11-03 01:30:00-0500 America/Chicago" is still datetime.replace().

ijs