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 <tritium-list@sdamon.com> 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.
On 07/31/2015 09:22 AM, Alexander Walters wrote: ...
"Is this instance of time DST? Oh, it has a member attribute 'is_dst', let me print that and see..."
That's a great reason _not_ to name the proposed attribute `is_dst`, because it does not answer the question "is this datetime DST?", and isn't intended to. The intent is to disambiguate times within the overlap resulting from a UTC-offset fallback, whether from DST or any other change in a timezone's UTC offset.
"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?"
If you are constructing a datetime in the middle of July, you have no need to set this attribute, because there are no ambiguous times in the middle of July. Your tzinfo (if it's useful) already knows that July is DST in your timezone, it doesn't need you to set any attribute manually. Carl
On Fri, Jul 31, 2015 at 11:36 AM, Carl Meyer <carl@oddbird.net> wrote:
If you are constructing a datetime in the middle of July, you have no need to set this attribute, because there are no ambiguous times in the middle of July.
That's if you are lucky. I mentioned this example before: Ukraine moved the clock back one hour on 1990-07-01. That was not in the middle of July, but close. This introduced an ambiguous hour where both the first and the second hour were in DST. (Yes, they kept observing STD/DST on top of that change, so they had two ambiguous hours in 1990.)
On Fri, Jul 31, 2015 at 11:22 AM, Alexander Walters <tritium-list@sdamon.com> wrote:
1. no one will expect the datetime module is_dst to map to the posix mktime function.
Please don't overgeneralize. The fact that *I* would expect "is_dst" in local to UTC converstion to act as the familiar "tm_isdst" does in local to "seconds since 1970-01-01T00:00 UTC" conversion is enough to invalidate your claim about "no one". I also suspect I am not alone.
If they expect a mapping to the posix api, they are using the time module.
For years, we recommended people who needed to translate naive datetimes assumed to be local to UTC to use datetime.utcfromtimestamp(time.mktime(dt.timetuple())). I think anyone who ever followed this recommendation will be surprised if we make "is_dst" behave differently from what "tm_isdst" does (on their platform!)
I think you are the only one who thought that.
I'll let others deny this. (Confirming this would take a world-wide poll.)
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.
POSIX's use of "tm_isdst" in mktime is as clear as mud. If you disagree, follow the link I posted before and read what the standard says before arguing that it is clear.
"Is this instance of time DST? Oh, it has a member attribute 'is_dst', let me print that and see..."
I have never had a need to answer the question "Is this instance of time DST?" What I normally want to know is the UTC offset. Most people I know have trouble telling whether DST is winter or summer time. If they know that for their location, most will get baffled if asked if this is the same in the other hemisphere. Please read the two dialogs I posted at the end of my proposal, <https://github.com/abalkin/ltdf/blob/master/README.rst#questions-and-answers>, and tell us who asks a better question Bob or Alice?
"I need to tell python this time I am inputting is DST. ...I will pass True to the is_dst argument"
That's the problem. Most people don't know whether they are inputing DST or STD and it does not matter 99.99% of the time. In that rare 0.01% case, that don't want to learn what DST is just to be able to pick between two possible times. It is much easier to decide whether you want something happen earlier or later than to decide whether you want it happen when DST is or is not (respectively) in effect.
"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?"
You know too much. :-) If you need a date in the middle of July - pick July 15.
On Fri, Jul 31, 2015 at 8:22 AM, Alexander Walters <tritium-list@sdamon.com> wrote:
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.
well, yes. but:
"Is this instance of time DST? Oh, it has a member attribute 'is_dst', let me print that and see..."
this is extending the use-case of the flag -- maybe a good idea, but not the original intent. As I understnd it the original intent is only to disambiguate the "the same time twice" case. "I need to tell python this time I am inputting is DST. ...I will pass
True to the is_dst argument"
why do you need to do that??? the point here is that you use the timezones definition od DST -- you don't need to think about it, except in the ambiguous case -- in which case, are you thining "Daylight vs Standard Time" or "first interval, or ??? "intuitive" means "works like I expect" -- but eveyone expects different things.... "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?"
nothing -- there is no ambiguity in the middle of July. -Chris -- Christopher Barker, Ph.D. Oceanographer Emergency Response Division NOAA/NOS/OR&R (206) 526-6959 voice 7600 Sand Point Way NE (206) 526-6329 fax Seattle, WA 98115 (206) 526-6317 main reception Chris.Barker@noaa.gov
participants (4)
-
Alexander Belopolsky -
Alexander Walters -
Carl Meyer -
Chris Barker