Extra transition type is generated by zic with -r specified
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. What I did: 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 -r /@4102444800 -d ./data rearguard.zi 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. These are local time transition types for Australia/Lord_Howe: Types gmtOffset (seconds),isDst,ttisgmt,ttisstd,[gmtOffset ISO],[DST?] 38180,0,,,PT10H36M20S,STD 0,0,,,PT0S,STD <- this is odd 36000,0,,,PT10H,STD 41400,1,,,PT11H30M,DST 37800,0,,,PT10H30M,STD 39600,1,,,PT11H,DST Transitions: transition,type,[UTC time],[Type offset],[Type isDST] … 4063275000,5,2098-10-04T15:30:00Z,PT11H,DST 4078998000,4,2099-04-04T15:00:00Z,PT10H30M,STD 4094724600,5,2099-10-03T15:30:00Z,PT11H,DST 4102444800,1,2100-01-01T00:00:00Z,PT0S,STD <- this is odd So, after the upper bound specified in -r, the transitions say that GMT is used. 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. Is that a bug or is there a reason for such behaviour? Thanks, Almaz Byte manipulations: typecnt is 5 in 32-bit section: xxd -seek 36(4+1+15+4*4) -len 4 data/Australia/Lord_Howe 64-bit section starts at offset 674. timecnt is 0xF0(=240) in 64-bit section: xxd -seek 706(674 + 20 + 3 * 4) -len 4 data/Australia/Lord_Howe typecnt is 6 in 64-bit section: xxd -seek 710(706 + 4) -len 4 data/Australia/Lord_Howe So, 64-bit header has one extra transition type. Let’s check how it is used and what that transition is: 2638 = 674 + 44 + 240 * 8 xxd -seek 2638 -len 240 -c 1 data/Australia/Lord_Howe prints transition types: 00000b38: 05 . 00000b39: 04 . 00000b3a: 05 . 00000b3b: 04 . 00000b3c: 05 . 00000b3d: 01 . Transition type is changing from 4 to 5, but the last one is 1. xxd -seek 2878 -len 36 -c 6 data/Australia/Lord_Howe prints local time type records: 00000b3e: 0000 9524 0004 ...$.. 00000b44: 0000 0000 0000 ...... <- the last transition type 00000b4a: 0000 8ca0 0008 ...... 00000b50: 0000 a1b8 010d ...... 00000b56: 0000 93a8 0013 ...... 00000b5c: 0000 9ab0 0119 ...... Which means that 1st type’s offset is 0 and that the last rule for Lord Howe is actually GMT.
On 10/25/21 04:18, Almaz Mingaleev via tz wrote:
Is that a bug or is there a reason for such behaviour?
The behavior you're describing comes from the following change that was circulated on the mailing list on October 15 and released in 2021e: https://mm.icann.org/pipermail/tz/2021-October/030980.html The idea is to let TZif readers know that the TZif file is truncated. Before this change, there was no way that a TZif reader would know that it's dealing with a truncated TZif file. The next draft of Internet RFC 8536bis is planned to recommend this sort of thing, unless some problems turn up with it (and if so, please let us know). We could modify zic to use some UT offset other than 0 for the affected timestamps; this would also follow the next draft's recommendation. Although I considered doing that, I worried that it'd be confusing for the TZif file to say that after the year 2100 Lord Howe Island will be at UT +11 with an abbreviation of "-00".
How feasible is it to add a flag which does not truncate the file? Also, RFC [1] says the following about TZ string: "the string MUST be consistent with the last version 2+ transition". Doesn't truncation violate that? [1] https://datatracker.ietf.org/doc/html/rfc8536#section-3.3 On Mon, 25 Oct 2021, 19:06 Paul Eggert, <eggert@cs.ucla.edu> wrote:
On 10/25/21 04:18, Almaz Mingaleev via tz wrote:
Is that a bug or is there a reason for such behaviour?
The behavior you're describing comes from the following change that was circulated on the mailing list on October 15 and released in 2021e:
https://mm.icann.org/pipermail/tz/2021-October/030980.html
The idea is to let TZif readers know that the TZif file is truncated. Before this change, there was no way that a TZif reader would know that it's dealing with a truncated TZif file.
The next draft of Internet RFC 8536bis is planned to recommend this sort of thing, unless some problems turn up with it (and if so, please let us know).
We could modify zic to use some UT offset other than 0 for the affected timestamps; this would also follow the next draft's recommendation. Although I considered doing that, I worried that it'd be confusing for the TZif file to say that after the year 2100 Lord Howe Island will be at UT +11 with an abbreviation of "-00".
On 10/25/21 11:15, Almaz Mingaleev wrote:
How feasible is it to add a flag which does not truncate the file?
The -r flag causes zic to truncate the file, so you can avoid truncation by not using the -r flag. Perhaps you meant "truncate the file in some other way"? What way would you like?
Also, RFC [1] says the following about TZ string: "the string MUST be consistent with the last version 2+ transition". Doesn't truncation violate that?
It's not an RFC conformance problem because the TZ string is empty in the truncated file, so there's nothing to be consistent with. The full quote from RFC 8536 is: "If the string is nonempty and one or more transitions appear in the version 2+ data, the string MUST be consistent with the last version 2+ transition."
I see it now, thanks. My goal was to generate transitions beyond 2038, not to truncate actually. On Mon, 25 Oct 2021 at 19:51, Paul Eggert <eggert@cs.ucla.edu> wrote:
On 10/25/21 11:15, Almaz Mingaleev wrote:
How feasible is it to add a flag which does not truncate the file?
The -r flag causes zic to truncate the file, so you can avoid truncation by not using the -r flag.
Perhaps you meant "truncate the file in some other way"? What way would you like?
Also, RFC [1] says the following about TZ string: "the string MUST be consistent with the last version 2+ transition". Doesn't truncation violate that?
It's not an RFC conformance problem because the TZ string is empty in the truncated file, so there's nothing to be consistent with. The full quote from RFC 8536 is: "If the string is nonempty and one or more transitions appear in the version 2+ data, the string MUST be consistent with the last version 2+ transition."
participants (2)
-
Almaz Mingaleev -
Paul Eggert