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#getDSTSavi... 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?