<div dir="ltr">I see, thanks.<div><br></div><div>Unfortunately such standard-to-standard time transitions break</div><div>DST offset finding logic on Android (code is here [1]). </div><div>For now I've reverted [2] (ironically the problem was reported by me).</div><div><br></div><div>Is there a less intrusive way to keep the old behaviour? </div><div><br></div><div>[1] <a href="https://android.googlesource.com/platform/external/icu/+/master/android_icu4j/libcore_bridge/src/java/com/android/i18n/timezone/ZoneInfoData.java#686" target="_blank">https://android.googlesource.com/platform/external/icu/+/master/android_icu4j/libcore_bridge/src/java/com/android/i18n/timezone/ZoneInfoData.java#686</a></div><div>[2] <a href="https://github.com/eggert/tz/commit/cec7d9e2e83f8a3faa2367e0d45383a1557889ed" target="_blank">https://github.com/eggert/tz/commit/cec7d9e2e83f8a3faa2367e0d45383a1557889ed</a></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, 22 Mar 2022 at 15:15, Paul Eggert <<a href="mailto:eggert@cs.ucla.edu" target="_blank">eggert@cs.ucla.edu</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">On 3/22/22 05:40, Almaz Mingaleev wrote:<br>
> Here are the last transitions in Africa/Casablanca output (rearguard<br>
> format):<br>
> <br>
> transition,type,[UTC time],[Type offset],[Type isDST]<br>
> <a href="tel:(367)%20261-2000" value="+13672612000" target="_blank">3672612000</a>,1,2086-05-19T02:00:00Z,PT1H,DST<br>
> 3699828000,2,2087-03-30T02:00:00Z,PT0S,STD<br>
> 3703456800,3,2087-05-11T02:00:00Z,PT1H,STD<br>
> <br>
> So change is from standard to standard, even though offset changes from 0h<br>
> to 1h. Is that expected behaviour?<br>
<br>
Yes, as tzdb frowns on permanent daylight saving time for reasons <br>
discussed recently.<br>
<br>
This issue occurs due to the rearguard format's contortion of post-2018 <br>
Morocco data to pretend that standard time is daylight saving and vice <br>
versa. Even with that contortion, we don't want the normal post-2087 <br>
prediction (standard time only) to be contorted into a rearguard <br>
post-2087 prediction of daylight saving only.<br>
</blockquote></div>