[Python-Dev] Draft PEP for time zone support. (original) (raw)

Guido van Rossum guido at python.org
Wed Dec 12 02:43:59 CET 2012

On Tue, Dec 11, 2012 at 5:11 PM, Robert Brewer <fumanchu at aminus.org> wrote:

Guido van Rossum wrote:

Sent: Tuesday, December 11, 2012 4:11 PM To: Antoine Pitrou Cc: python-dev at python.org Subject: Re: [Python-Dev] Draft PEP for time zone support.

On Tue, Dec 11, 2012 at 8:07 AM, Antoine Pitrou <solipsis at pitrou.net> wrote: > Le Tue, 11 Dec 2012 16:23:37 +0100, > Lennart Regebro <regebro at gmail.com> a écrit : >> >> Changes in the datetime-module >> -------------------------------------- >> >> A new isdst parameter is added to several of the tzinfo >> methods to handle time ambiguity during DST changeovers. >> >> * tzinfo.utcoffset(self, dt, isdst=True) >> >> * tzinfo.dst(self, dt, isdst=True) >> >> * tzinfo.tzname(self, dt, isdst=True) >> >> The isdst parameter can be True (default), False, or >> None. >> >> True will specify that the given datetime should be interpreted >> as happening during daylight savings time, ie that the time specified >> is before the change from DST. > > Why is it True by default? Do we have statistics showing that Python > gets more use in summer? My question exactly. "Summer" in the USA, at least, is 238 days in 2012, while "Winter" into 2013 is only 126 days:

import datetime datetime.date(2012, 11, 4) - datetime.date(2012, 3, 11) datetime.timedelta(238) datetime.date(2013, 3, 10) - datetime.date(2012, 11, 4) datetime.timedelta(126)

Very funny, but that can't be the real reason. Most datetime values aren't ambiguous, so in those cases the parameter should be ignored, right? There's only one hour per year where you need to specify it (two, if we want to artificially assign a meaning to values falling the impossible hour). And during those times it's equally likely that you meant either of the possibilities. I think the meaning of the parameter must be clarified, perhaps as follows:

Here I'd prefer the default to be None if I had to do it over again, but given that the current behavior is one of the first two (which one?) we probably can't do that. Still, it's slightly confusing that passing None is not the same as omitting the parameter altogether -- there aren't many APIs that explicitly support passing None but don't use it as the default (though there probably are some precedents). Maybe requesting an error should be done through some other special value, and None should be the same as omitted and the same as the old behavior? But where would the special value come from? It should be made as easy as possible to "do the right thing" (i.e. raise an error). Or maybe have a separate Boolean flag to request an error?

-- --Guido van Rossum (python.org/~guido)

More information about the Python-Dev mailing list