[tz] Unexpected last transition in Africa/Casablanca

Almaz Mingaleev mingaleev at google.com
Tue Mar 22 12:40:17 UTC 2022


Hi Paul,
Here are the last transitions in Africa/Casablanca output (rearguard
format):

transition,type,[UTC time],[Type offset],[Type isDST]
3672612000,1,2086-05-19T02:00:00Z,PT1H,DST
3699828000,2,2087-03-30T02:00:00Z,PT0S,STD
3703456800,3,2087-05-11T02:00:00Z,PT1H,STD

So change is from standard to standard, even though offset changes from 0h
to 1h. Is that expected behaviour?

As Africa/El_Aaiun is using Morocco rules, its transitions are also
affected.
This affects 64-bit section only, 32-bit section looks fine to me.

Thanks,
Almaz


Data above is output of debug tools used in Android. The way I've built
data an byte manipulations if needed:

mkdir /tmp/zic
cd /tmp/zic
git clone https://github.com/eggert/tz.git .
make -C . zic
make -C . NDATA= rearguard.zi
mkdir data
./zic -b fat -d ./data rearguard.zi

byte manipulations:
Let's skip 32-bit header:
xxd -seek 20 -c 4 -l 24 data/Africa/Casablanca
typecnt: 94
timecnt: 5
charcnt: 12

32-bit block size = 94 * 4 + 94 + 5 * 6 + 12 = 512
64-bit start = 44 + 512 = 556

64-bit header:
xxd -seek 576 -c 4 -l 24 data/Africa/Casablanca:
timecnt: 196
typecnt: 4      <- 32-bit section has 5
charcnt: 12

transition types offset: 556 + 44 + 196 * 8  = 2168

xxd -seek 2168 -c 1 -l 196 data/Africa/Casablanca
...
00000934: 02  .
00000935: 01  .
00000936: 02  .
00000937: 01  .
00000938: 02  .
00000939: 01  .
0000093a: 02  .
0000093b: 03  . <- the last transition

local time records offset = 556 + 44 + 196 * 9 = 2364

xxd -seek 2364 -c 6 -l 24 data/Africa/Casablanca
0000093c: ffff f8e4 0000  ......
00000942: 0000 0e10 0104  ......
00000948: 0000 0000 0008  ...... <- standard time
0000094e: 0000 0e10 0004  ...... <- also standard time
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mm.icann.org/pipermail/tz/attachments/20220322/e2d7602d/attachment.html>


More information about the tz mailing list