[tz] Unexpected last transition in Africa/Casablanca
eggert at cs.ucla.edu
Mon Mar 28 17:33:36 UTC 2022
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 ).
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:
> - - +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?
More information about the tz