[Datetime-SIG] What's are the issues?

[Alexander Belopolsky]

On Wed, Jul 29, 2015 at 1:05 PM, Lennart Regebro <regebro at gmail.com> wrote:
>> Not so.  It can easily (albeit rarely) arise in cases of pure timezone
>> conversions.  Conversions have nothing to do with arithmetic.  If I
>> convert a time in zone X to a time in zone Y that lands in an
>> ambiguous span in zone Y, without the conversion _also_ setting an
>> is_dst flag in the destination, it's impossible to reliably convert
>> the time in zone Y back to zone X again.
>
> No, you just consistently pick one of the two times in both
> conversions to and from and it will roundtrip just fine.

This may work when both conversions have an ambiguity, but in the real
life this does not happen.

Assume the time difference between X and Y in 12 hours, and naturally
Y does not have a DST transition in the middle of the day.

Let's start the conversion:

"01:30 X/DST" -> "13:30 Y" ->  "01:30 X/DST"

So far so good.  We ignore DST in the first transition, get
unambiguous time in the Y zone and get the original X time in the
second transition.

However, we we start with "01:30 X/STD", we must get

"01:30 X/STD" -> "13:30 Y"

by the first rule and have no choice but follow with

 "13:30 Y" ->  "01:30 X/DST"

and the round-trip mutates STD to DST.

The only way to solve it is to take into account the "STD" marker in
the first transition and map

"01:30 X/STD" -> "14:30 Y" -> "01:30 X/STD",

but you cannot take into account the "STD" marker if it is not there
to begin with.