<div dir="ltr">I’ve tried to generate a TZif file with transitions up to 1 Jan 2100 using zic with -r and “-b fat”. However, an extra transition type is generated for many (all?) time zones. That type’s UTC offset is zero and it is used only for the last transition in the 64-bit section.<br><br>What I did:<br>mkdir /tmp/zic <br>cd /tmp/zic<br>git clone <a href="https://github.com/eggert/tz.git">https://github.com/eggert/tz.git</a> .<br>make -C . zic<br>make -C . NDATA= rearguard.zi<br>mkdir data<br>./zic -b fat -r /@4102444800 -d ./data rearguard.zi<br><br>Below is an investigation for Australia/Lord_Howe (I don’t think choice matters here). I couldn’t find a way to force zdump to print transitions for a given TZif file. Instead, please see human-readable dumps from the TZif from our internal tools immediately below and raw byte information at the bottom if you’d prefer to work with that.<br><br>These are local time transition types for Australia/Lord_Howe:<br>Types<br>gmtOffset (seconds),isDst,ttisgmt,ttisstd,[gmtOffset ISO],[DST?]<br>38180,0,,,PT10H36M20S,STD<br>0,0,,,PT0S,STD                          <- this is odd<br>36000,0,,,PT10H,STD<br>41400,1,,,PT11H30M,DST<br>37800,0,,,PT10H30M,STD<br>39600,1,,,PT11H,DST<br><br>Transitions:<br>transition,type,[UTC time],[Type offset],[Type isDST]<br>…<br>4063275000,5,2098-10-04T15:30:00Z,PT11H,DST<br>4078998000,4,2099-04-04T15:00:00Z,PT10H30M,STD<br>4094724600,5,2099-10-03T15:30:00Z,PT11H,DST<br>4102444800,1,2100-01-01T00:00:00Z,PT0S,STD     <- this is odd<br><br>So, after the upper bound specified in -r, the transitions say that GMT is used.<br><br>As I’d expect, the 32-bit transitions are not affected when the upper bound in -r is after 2038. However, with -r /@1634833073 the 32-bit section also has 6 transition types and the last transition sets offset to 0.<br><br>Is that a bug or is there a reason for such behaviour?<br><br>Thanks,<div>Almaz<br><br>Byte manipulations:<br><br>typecnt is 5 in 32-bit section: xxd -seek 36(4+1+15+4*4) -len 4 data/Australia/Lord_Howe<br>64-bit section starts at offset 674.<br>timecnt is 0xF0(=240) in 64-bit section: xxd -seek 706(674 + 20 + 3 * 4) -len 4 data/Australia/Lord_Howe<br>typecnt is 6 in 64-bit section: xxd -seek 710(706 + 4) -len 4 data/Australia/Lord_Howe<br>So, 64-bit header has one extra transition type. <br><br>Let’s check how it is used and what that transition is:<br>2638 = 674 + 44 + 240 * 8<br>xxd -seek 2638 -len 240 -c 1 data/Australia/Lord_Howe prints transition types:<br>00000b38: 05  .<br>00000b39: 04  .<br>00000b3a: 05  .<br>00000b3b: 04  .<br>00000b3c: 05  .<br>00000b3d: 01  .<br><br>Transition type is changing from 4 to 5, but the last one is 1.<br>xxd -seek 2878 -len 36 -c 6 data/Australia/Lord_Howe prints local time type records:<br>00000b3e: 0000 9524 0004  ...$..<br>00000b44: 0000 0000 0000  ......   <- the last transition type<br>00000b4a: 0000 8ca0 0008  ......<br>00000b50: 0000 a1b8 010d  ......<br>00000b56: 0000 93a8 0013  ......<br>00000b5c: 0000 9ab0 0119  ......<br><br>Which means that 1st type’s offset is 0 and that the last rule for Lord Howe is actually GMT.<br></div></div>