[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