On Mon, Jul 27, 2015 at 11:42 AM, Ryan Hiebert firstname.lastname@example.org wrote:
On Jul 27, 2015, at 10:37 AM, Alexander Belopolsky <
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  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.