On Mon, Jul 27, 2015 at 11:42 AM, Ryan Hiebert <ryan@ryanhiebert.com> wrote:
> On Jul 27, 2015, at 10:37 AM, Alexander Belopolsky <alexander.belopolsky@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