[Python-Dev] Draft PEP for time zone support.

[Christian Tismer]

On 12.12.12 02:43, Guido van Rossum wrote:
> 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 ``is_dst`` parameter is added to several of the `tzinfo`
>>>>> methods to handle time ambiguity during DST changeovers.
>>>>>
>>>>> * ``tzinfo.utcoffset(self, dt, is_dst=True)``
>>>>>
>>>>> * ``tzinfo.dst(self, dt, is_dst=True)``
>>>>>
>>>>> * ``tzinfo.tzname(self, dt, is_dst=True)``
>>>>>
>>>>> The ``is_dst`` 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:
>
> - ignored except during the ambiguous hour and during the impossible hour
> - during the ambiguous or impossible hour:
>    - if True, prefer/pretend DST
>    - if False, prefer/pretend non-DST
>    - if None, raise an error
>
> 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?
>

I see an issue here that makes me a little uncomfortable:
Having a default that makes code work all year but raises an error during
the "impossible hour" could be problematic in critical code.
Can we make this more explicit by forcing the users to decide?

I like the idea of the extra boolean flag here, because it will be 
explicitly
visible that this code intentionally creates an exception.
Or even not a flag, but the exception to be raised, or a callable to
handle this case?

Sloppy coding can be dangerous. So maybe the warning module could be
helpful as well: If None is passed and no explicit flag/exception/callable
given, bother the user with a warning message ;-)

cheers - chris

-- 
Christian Tismer             :^)<mailto:tismer at stackless.com>
Software Consulting          :     Have a break! Take a ride on Python's
Karl-Liebknecht-Str. 121     :    *Starship*http://starship.python.net/
14482 Potsdam                :     PGP key ->http://pgp.uni-mainz.de
phone +49 173 24 18 776  fax +49 (30) 700143-0023
PGP 0x57F3BF04       9064 F4E1 D754 C2FF 1619  305B C09C 5A3B 57F3 BF04
       whom do you want to sponsor today?http://www.stackless.com/