Re: [Datetime-SIG] Local time disambiguation proposal
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:
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
On Thu, Jul 30, 2015 at 2:15 PM, Alexander Walters
wrote: 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.
participants (4)
-
Alexander Belopolsky
-
Alexander Walters
-
Carl Meyer
-
Chris Barker