<html><head><meta http-equiv="Content-Type" content="text/html; charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class="">OK, that makes sense. Any dissent?<div class=""><br class=""></div><div class="">Thanks,</div><div class="">Debbie</div><div class=""><div><br class=""><blockquote type="cite" class=""><div class="">On Jan 4, 2019, at 12:33 PM, Tim Parenti <<a href="mailto:tim@timtimeonline.com" class="">tim@timtimeonline.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div dir="ltr" class=""><div dir="ltr" class=""><div class=""><div dir="ltr" class=""><br class="gmail-Apple-interchange-newline">On Fri, 4 Jan 2019 at 14:43, Deborah Goldsmith via tz <<a href="mailto:tz@iana.org" class="">tz@iana.org</a>> wrote:<br class=""></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Here’s the (partial) diff of transitions that results from 2018i vs. 2018g (both generated from rearguard tarballs):<br class=""><br class=""> Africa/Casablanca Sun Jun 17 01:59:59 2018 UTC = Sun Jun 17 01:59:59 2018 +00 isdst=0<br class=""> Africa/Casablanca Sun Jun 17 02:00:00 2018 UTC = Sun Jun 17 03:00:00 2018 +01 isdst=1<br class="">-Africa/Casablanca Fri Oct 26 22:59:59 2018 UTC = Fri Oct 26 23:59:59 2018 +01 isdst=1<br class="">-Africa/Casablanca Fri Oct 26 23:00:00 2018 UTC = Sat Oct 27 00:00:00 2018 +01 isdst=0<br class="">-Africa/Casablanca Mon Jan 18 03:14:07 2038 UTC = Mon Jan 18 04:14:07 2038 +01 isdst=0<br class="">-Africa/Casablanca Tue Jan 19 03:14:07 2038 UTC = Tue Jan 19 04:14:07 2038 +01 isdst=0<br class="">+Africa/Casablanca Sun May 5 01:59:59 2019 UTC = Sun May 5 02:59:59 2019 +01 isdst=1<br class="">+Africa/Casablanca Sun May 5 02:00:00 2019 UTC = Sun May 5 02:00:00 2019 +00 isdst=0<br class=""><br class="">Debbie</blockquote></div><div class=""><br class=""></div><div class="">The issue seems to have been introduced in ziguard.awk at <a href="https://github.com/eggert/tz/blob/8539a448ebc8897e40d62f16dc4d0ada3f07b3ca/ziguard.awk#L93-L96" class="">https://github.com/eggert/tz/blob/8539a448ebc8897e40d62f16dc4d0ada3f07b3ca/ziguard.awk#L93-L96</a> in <a href="https://github.com/eggert/tz/commit/8539a448ebc8897e40d62f16dc4d0ada3f07b3ca" class="">8539a44</a>, which is causing the substitution.</div><div class=""><br class=""></div><div class="">Though I will admit it was not straightforward deriving the intent of that substitution from the comments, it is there because the 2018-10-26 transition was NOT a transition in UT offset. In a rearguard sense, 2018g predicted that the new timezone of +01 would be permanent and thus switched to +01 with rearguard isdst=0 on 2018-10-26. As it is now expected that Morocco will "fall back" to +00 each Ramadan, 2018h and 2018i consider rearguard isdst to have instead remained 1 on 2018-10-26 (since there was no clock change), and that the flag will become rearguard isdst=0 when the clocks fall back each Ramadan.</div><div class=""><br class=""></div><div class="">(The vanguard format, by contrast, considers +01 the new "standard" time effective 2018-10-26, which would show up as a transition from +01, isdst=1 to +01, isdst=0; and Ramadan is considered to have negative DST.)</div><div class=""><br class=""></div><div class="">So the diff you're seeing here, best I can tell, reflects expected behavior and accurate data for Morocco in 2018h and 2018i.</div><br clear="all" class=""><div class=""><div dir="ltr" class="gmail_signature" data-smartmail="gmail_signature">--<br class="">Tim Parenti</div></div></div></div>
</div></blockquote></div><br class=""></div></body></html>