[Datetime-SIG] PEP-431/495

[Stuart Bishop]

On 27 August 2015 at 21:05, Alexander Belopolsky
<alexander.belopolsky at gmail.com> wrote:
>
> On Thu, Aug 27, 2015 at 9:12 AM, Stuart Bishop <stuart at stuartbishop.net>
> wrote:
>>
>> But, really, I hate all the options for the flag name. I lean towards
>> is_dst mainly because people are used to it.
>
> Ironically, you created one of the reasons I did not want any mention of
> "dst" in the new attribute: the way pytz's localize() uses is_dst is so
> different from the way mktime() uses tm_isdst, that creating a third set of
> rules for a variable with a similar name was out of the question.
>
> If you have time, please re-read the answer to "Why not call the new flag
> 'isdst'?" [1] in the PEP and let me know if it needs any improvements.
>
> [1]:
> https://www.python.org/dev/peps/pep-0495/#why-not-call-the-new-flag-isdst

In my experience, the first conversation would actually read:

Alice: Hey, lets watch the meteor shower at 1:30am
Bob: Is that 1:30am daylight savings time?
Alice: Hmm... yes, the paper says daylight savings time.

I think people are more aware of daylight savings time than you
imagine, given the nagging by the media on how to adjust their clocks.

Most of the argument against isdst also applies to first/fold.

I think you are more likely to know if you want dst or not than you
are to know if you want the first or second period. Most of my input
comes from other computer systems, and will give me an offset. This is
more easily mapped to the is_dst flag than the fold flag.

If you have the dst flag, then you need details about the timezone to
calculate the fold flag. In all cases, if you chose not to or are
unable to specify an explicit flag you are forced to guess and will
get the incorrect answer 50% of the time.

While most of the time you will just guess with either approach, I
think you are more likely to get disambiguation information from a
computer in the form of an offset or is_dst flag than you are to get
disambiguation information from a human.

I have billions of rows of data in my databases. If I'm dealing with
input from computer systems, such as my databases, I will have
billions of conversions to do and the overhead of calculating the fold
flag is billions of times worse than calculating the isdst flag from
the non-bulk human input.

Yes, there is a subtle difference between how tm_isdst is handled and
how an is_dst flag in the datetime module should be handled, in that
tm_isdst will force the use of the dst timezone or not even if it
would normally not be applied to that period. Personally, I find the
behaviour close enough that the similar names would be a benefit.

Yes, the dst() method returning the dst offset and the is_dst flag are
have similar names, which is fine as they have similar concepts. The
proposed type checking would ensure that any misinterpretation was
quickly picked up, as attempting to pass timedelta(0) as the value of
is_dst would raise an exception.

So I think the argument against is_dst is weak. That said, I can't
make a strong argument in favour of it either. I still lean in favour
of is_dst myself, but I'm only leaning.



-- 
Stuart Bishop <stuart at stuartbishop.net>
http://www.stuartbishop.net/