On Mon, Jul 27, 2015 at 11:42 AM, Ryan Hiebert <r...@ryanhiebert.com> wrote:
> > On Jul 27, 2015, at 10:37 AM, Alexander Belopolsky <
> alexander.belopol...@gmail.com> wrote:
> >
> > On the other hand, these rare events are not that different from more or
> less regular DST
> > transitions. You still have either a non-existent or ambiguous local
> times interval and
> > you can resolve the ambiguity by adding 1 bit of information. The only
> question is what
> > should we call the flag that will supply that information? IMO, "isdst"
> is a wrong name
> > for dealing with the event I described above.
>
> While I see your point that isdst is the wrong name in that it doesn't
> describe what's actually happening in all cases, it is the most well known
> instance of the issue, and I personally think that using isdst for the
> other cases makes sense, and that they would disambiguate in the same
> direction that it would in a dst transition of the same type (clocks
> forward or backward).
Well, my specific proposal in [1] was to also change the semantics. The
proposed "which" flag would have the following
meaning:
1. If local time is valid and unambiguous, "which" is ignored.
2. If local time is ambiguous, which=0 means the first and which=1 means
the second (chronologically).
3. If local time is invalid, which=0 means the time extrapolated from
before the transition and
which = 1 means the time extrapolated from after the transition.
Note that these rules have some nice properties: if t is ambiguous, UTC(t,
which=0) < UTC(t, which=1)
and if t is invalid, UTC(t, which=0) > UTC(t, which=1). This property can
be used to take different
actions in those cases. The result for ambiguous t and which=0 has a
natural interpretation as time
specified by a user not aware of the clock change.
I think these rules are simpler and more natural than those for isdst which
takes 3 values: 0, 1 and -1 and
the rules for -1 vary between implementations. Under my proposal
unspecified "which" means which=0.
[1]: https://mail.python.org/pipermail/python-dev/2015-April/139099.html
_______________________________________________
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
