[tz] Unexpected last transition in Africa/Casablanca

[Almaz Mingaleev]

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 at 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?
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mm.icann.org/pipermail/tz/attachments/20220329/9d10453b/attachment.html>