I suspect it's a similar prime On March 28, 2022 5:33:36 PM UTC, Paul Eggert via tz <tz@iana.org> wrote:
On 3/28/22 09:03, Almaz Mingaleev wrote:
Unfortunately such standard-to-standard time transitions break DST offset finding logic on Android (code is here [1]).
Could you explain the problem more? There are lots of places where timezones switch from one standard time to another, and evidently these other transitions don't cause a problem. What's different here?
Here's the output of 'zdump -i -c 2085,2100 Africa/Casablanca' if you're using rearguard format:
TZ="Africa/Casablanca" - - +01 1 2085-04-22 02 +00 2085-06-03 03 +01 1 2086-04-14 02 +00 2086-05-19 03 +01 1 2087-03-30 02 +00 2087-05-11 03 +01
If we want the last line to be standard time, what should the previous lines look like if we want to avoid the Android transition-finding problem? For example, would it be OK if the penultimate line were absent?