<div dir="ltr"><div style="font-family:arial,helvetica,sans-serif" class="gmail_default"></div><div dir="ltr"><div class="gmail_default" style="font-family:arial,helvetica,sans-serif">Got it, thanks for the clarification, it helps to have more context about what you were thinking. I was focused on Grand_Turk, so probably simplified my exposition too much. I think the better explanation is that the 2:00 in the UNTIL field precisely matches  the 2:00 in the AT in the US Rule, so there is only one transition, instead of 2 transitions. Same thing seems to happen with the 2:00s in the UNTIL for Kaliningrad, which matches the 2:00s in the AT for the Russia Rule.</div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif"><br></div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif">The thing that I was wondering  was whether the semantics of the zone info text files actually mandated a transition from 2:00 to 1:00 for Grand_Turk, if the Zone entry  was set to 2:00, instead of its current 3:00 value. Or whether the special case in the zic compiler was an additional rule on top of the normal semantics of the zone info text files, in order to parse the Grand_Turk case properly. I managed to convince myself that the normal rules of the text files were sufficient for Grand_Turk. And my parsing code seems to implement those normal rules properly.<br></div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif"><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, Dec 29, 2020 at 4:11 PM Michael H Deckers <<a href="mailto:michael.h.deckers@googlemail.com">michael.h.deckers@googlemail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><br>
     On 2020-12-29 22:45, Brian Park wrote:<br>
> Then I wish you had said exactly that, instead of having me go off on a<br>
> tangent.<br>
<br>
<br>
    So do I. I am sorry to have lead you astray.<br>
<br>
> Maybe I am misinterpreting something, but I don't understand why<br>
> you are being confrontational about this. I am presenting results from 2<br>
> different TZ parsers, using algorithms developed independently. I thought<br>
> this would be interesting and relevant to this topic.<br>
<br>
<br>
    I do not want to sound confrontational but I do<br>
    want to be short. My comment on your original post<br>
    concerned only one sentence, and I did in no way<br>
    comment on the rest of that post.<br>
<br>
<br>
>   I don't understand<br>
> the point that you are trying to make.<br>
<br>
    The complete sentence I commented about is:<br>
<br>
       The core of why it "just works" seems be in the interpretation<br>
       of the "2:00 transition to US Rule", and the fact that "2:00"<br>
       is Wall-time, not S-time or U-time:<br>
<br>
    I understand this to imply that a time of day value with<br>
    a postfix "s" or "u" in the UNTIL column would preclude<br>
    that it "just works".<br>
<br>
    Now there are cases where two transitions (an increase<br>
    in SAVE value after a decrease in STDOFF) are colaesced,<br>
    and where the corresponding UNTIL column has a time of<br>
    day value with a postfixed "s"; one example is for<br>
    Kaliningrad.<br>
<br>
    My comment asks how your code deals with such cases,<br>
    given that it would not "just work".<br>
<br>
    I hope this makes my point clear(er).<br>
<br>
    Michael Deckers.<br>
<br>
</blockquote></div></div>