There are APIs like TimeZone.getDSTSavings [1]. As of now we calculate it
as the difference between the last DST and standard offsets in the
transition table. As the last transition is marked as standard these offsets are
equal, and the method returns 0, which is wrong.

> would it be OK if the penultimate line were absent?
Removing the last transition would help. 

[1] https://docs.oracle.com/javase/8/docs/api/java/util/TimeZone.html#getDSTSavings--

On Mon, 28 Mar 2022 at 18:33, Paul Eggert <eggert@cs.ucla.edu> 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?