On 27 August 2015 at 21:05, Alexander Belopolsky <alexander.belopolsky@gmail.com> wrote:

On Thu, Aug 27, 2015 at 9:12 AM, Stuart Bishop <stuart@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@stuartbishop.net> http://www.stuartbishop.net/