[Datetime-SIG] Local time disambiguation proposal

[Alexander Walters]

1.  no one will expect the datetime module is_dst to map to the posix 
mktime function.  If they expect a mapping to the posix api, they are 
using the time module.  I think you are the only one who thought that.  
Just because another api uses a clear term with one set of semantics, 
does not mean we cant use the clear term with a different set of semantics.

2.

"Is this instance of time DST?  Oh, it has a member attribute 'is_dst', 
let me print that and see..."

"I need to tell python this time I am inputting is DST.  ...I will pass 
True to the is_dst argument"

"I am in the northern hemisphere and need to construct a date in the 
middle of july.  My nation-state observes DST.  ...what the hell do i do 
with a 'first' argument?"

On 7/30/2015 14:33, Alexander Belopolsky wrote:
> On Thu, Jul 30, 2015 at 2:15 PM, Alexander Walters
> <tritium-list at sdamon.com> wrote:
>> We are not talking about implementing the POSiX argument to mktime, and I
>> dont think anyone on the list ever was.  .is_dst is a bool flag for 'if set,
>> the time represented is in the DST time, if not set, it is in the non-DST
>> time'.
>>
>> '.first' doesnt even imply a bool.  "First what?" someone might ask.
> I have no emotional attachment to any particular name.  If you like
> "is_first" better than "first" on the grammatical grounds - I have no
> problem changing the spelling.
>
> I do have two problems with calling it isdst:
>
> 1. Whether we want to implement the POSIX standard or not, but
> tm_isdst member is the POSIX solution to the problem at hand and if we
> give datetime objects a member variable called isdst, but change the
> semantics, we will see no end of bug reports.  (And since no one
> understands POSIX semantics, we have no choice but to change them. :-)
>
> 2. It will be very confusing to have t.is_dst ≠ t.dst()  which will
> happen whenever you have an ambiguity due to a change in the standard
> time.