[Datetime-SIG] Local time disambiguation proposal

[Alexander Belopolsky]

On Fri, Jul 31, 2015 at 11:22 AM, Alexander Walters
<tritium-list at 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.