<div dir="ltr">This is more of an awareness-raising post than anything else... the data here is very far in the past.<div><br></div><div>While trying to validate Noda Time against zic, I came up against issues with data releases between 1993 and 1996 in Egypt/Cairo. It turns out that this is because the Egypt rule is duplicated in the asia file, and this affects things.</div><div><br></div><div>As a smallish example, if you create a file called testzone like this:</div><div><br></div><div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><font face="monospace, monospace">Rule    Egypt   1900    only    -       Oct      1      0:00    0       -<br></font><font face="monospace, monospace">Rule    Egypt   1943    1945    -       Nov      1      0:00    0       -<br></font><font face="monospace, monospace">Rule    Egypt   1945    only    -       Apr     16      0:00    1:00    &quot; DST&quot;<br></font><font face="monospace, monospace">Rule    Egypt   1957    only    -       May     10      0:00    1:00    &quot; DST&quot;<br></font><font face="monospace, monospace">Rule    Egypt   1957    1958    -       Oct      1      0:00    0       -<br></font><font face="monospace, monospace">Rule    Egypt   1958    only    -       May      1      0:00    1:00    &quot; DST&quot;</font><font face="monospace, monospace"><br></font><font face="monospace, monospace"># Rule  Egypt   1957    only    -       May     10      0:00    1:00    &quot; DST&quot;</font><font face="monospace, monospace"><br></font><font face="monospace, monospace"><br></font><font face="monospace, monospace"># Zone  NAME            GMTOFF  RULES   FORMAT  [UNTIL]<br></font><font face="monospace, monospace">Zone    Africa/Cairo    2:05:00 -       LMT     1900 Oct<br></font><font face="monospace, monospace">                        2:00    Egypt   EET%s</font></blockquote></div><div><br></div><div>... then execute:</div><div><br></div><div><div>$ zic -d . testzone &amp;&amp; zdump -v -c 1955,1958 $PWD/Africa/Cairo</div></div><div><br></div><div>You&#39;ll see output like this for the May 1957 transition:</div><div><br></div><div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">.../Africa/Cairo  Thu May  9 21:59:59 1957 UT = Thu May  9 23:59:59 1957 EET isdst=0 gmtoff=7200<br>...Africa/Cairo  Thu May  9 22:00:00 1957 UT = Fri May 10 01:00:00 1957 EET DST isdst=1 gmtoff=10800</blockquote></div><div><br></div><div>That looks okay - the transition is around midnight, as described.</div><div><br></div><div>If, however, you uncomment that last &quot;Rule&quot; line above - which is an exact duplicate of the earlier one - you get:</div><div><br></div><div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">.../Africa/Cairo  Thu May  9 20:59:59 1957 UT = Thu May  9 22:59:59 1957 EET isdst=0 gmtoff=7200<br>.../Africa/Cairo  Thu May  9 21:00:00 1957 UT = Fri May 10 00:00:00 1957 EET DST isdst=1 gmtoff=10800</blockquote></div><div><br></div><div>Now the transition is one hour earlier.</div><div><br></div><div>As it happens, this duplicate rule doesn&#39;t make any difference to Noda Time - it still emits the first output.</div><div><br></div><div>I <i>strongly suspect</i> that I shouldn&#39;t care about this - that situations with duplicate rules should be deemed out of scope for any implementation. However, if anyone can think of any good justification why an implementation <i>should</i> behave like zic in this case, I&#39;d be really interested to hear it.</div><div><br></div><div>(I&#39;m not asking for zic to change here. It already emits a warning because the rule is defined in multiple files, and I think that&#39;s good enough.)</div><div><br></div><div>Jon</div><div><br></div></div>