[tz] Unexpected last transition in Africa/Casablanca

[Paul Eggert]

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?