<div dir="ltr"><br>On Thu, Jul 28, 2016 at 1:23 AM, Paul Eggert &lt;<a href="mailto:eggert@cs.ucla.edu">eggert@cs.ucla.edu</a>&gt; wrote:<br>&gt;&gt;<br>&gt;&gt; I think a better solution would be to make zic add a redundant transition<br>&gt;&gt; when the local time type corresponding to the last transition does not<br>&gt;&gt; match the POSIX rule.<br>&gt;<br>&gt;<br>&gt; ... How about a belt-and-suspenders approach? That is, add the redundant transition, but also fix localtime.c to implement the documented behavior.<br><br><br>I am not sure I would go that far.  Note that the glibc behavior on the current Africa/Casablanca tzfile is puzzling: the 2037-10-04 transition does not show in the zdump output even though it is present in the tzfile.  Furthermore, there are projects other than tzcode that implement tzcode behavior for example Ruby&#39;s TZInfo::Data project decided [1] that they would follow tzcode logic.<div><br></div><div>I think the best way forward would be to document the fact that a tzfile with the last explicit transition not matching a POSIX rule transition is invalid and the behavior of localtime with such file is undefined.</div><div><br></div><div>I suggest fixing the issue in two steps:</div><div><br></div><div>1. Add 2038-03-28 transition to the Morocco rules in the raw africa file.</div><div>2. Modify zic to warn about raw files where the last explicit transition does not match the rule from the POSIX string and add an appropriate transition in the binary file.</div><div><br></div><div>Note that the first step will be sufficient to fix the current issue while the second step will prevent a similar issue from occurring in the future.<br><br><br>[1] <a href="https://github.com/tzinfo/tzinfo-data/issues/10">https://github.com/tzinfo/tzinfo-data/issues/10</a><br></div></div>