[tz] Unexpected last transition in Africa/Casablanca

Paul Eggert eggert at cs.ucla.edu
Wed May 18 17:41:22 UTC 2022


On 5/18/22 02:32, Almaz Mingaleev wrote:

> Unfortunately changing isdst flag only won't help here - in this case the
> last
> DST and STD transition offsets are equal, which breaks DST savings finding
> logic - it would return 0, as in my first email, where last DST and STD
> offsets
> are 1 hour.
> 
> On Wed, 30 Mar 2022 at 19:36, Paul Eggert <eggert at cs.ucla.edu> wrote:...
>> perhaps we should revert all these workarounds, and go back
>> to what we were doing in this area before commit
>> cec7d9e2e83f8a3faa2367e0d45383a1557889ed dated 2022-01-10 11:31:54 -08.

OK, in that case let's revert as mentioned above. I installed the 
attached proposed patch into the development repository.

It is a bit disconcerting to see comments like the following 
<https://android.googlesource.com/platform/external/icu/+/master/android_icu4j/libcore_bridge/src/java/com/android/i18n/timezone/ZoneInfoData.java#716>:

>             // This test means that for somewhere like Morocco, which tried DST in 2009 but has
>             // no future plans (and thus no future schedule info) will report "true" from
>             // useDaylightTime at the start of 2009 but "false" at the end. This seems appropriate

which indicates that the code (or at least its commentary) doesn't match 
reality, as Morocco obviously is using DST now (whichever way you model 
it). It's not good that TZDB now has yet another rearguard hack to work 
around the code's mismatch with reality.

What would it take to get this fixed properly in Android and ICU and 
Java, and to support negative DST and all that? I know this can't be 
fixed overnight, but what would it take for a fix in the long run? As I 
understand it, Java currently can't even handle POSIX TZ strings much 
less TZDB data, and surely this is undesirable even aside from TZDB.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-Go-back-to-2021e-Morocco-rearguard-workaround.patch
Type: text/x-patch
Size: 2474 bytes
Desc: not available
URL: <https://mm.icann.org/pipermail/tz/attachments/20220518/950393be/0001-Go-back-to-2021e-Morocco-rearguard-workaround.patch>


More information about the tz mailing list