On Thu, 14 Mar 2019 at 12:26, Paul Eggert <eggert@cs.ucla.edu> wrote:
On 3/11/19 8:35 PM, Tim Parenti wrote:
So if my truncation range starts with POSIX timestamp N, I would expect time type zero to correctly and accurately represent timestamp N−1 (though, of course, not necessarily N−2 or any earlier).
Thanks for catching that bug. I installed the attached patch.
Thanks, though I should note I have a quibble with a small assertion in your patch notes: It’s nicer (though not required by RFC 8536) that when the start of a TZif
file is truncated, the default time type is that of timestamps just before the first transition.
Section 5.1 of RFC 8536 requires that "[a]ll represented information that falls inside the truncation range MUST be the same as that represented by a corresponding untruncated TZif file." By not making the default time type that of timestamps just before the range starts at time N, this creates a false and inaccurate transition at time N. By ensuring that timestamp N−1 is accurately represented, either a correct transition is inserted at time N (if a transition does indeed normally exist at time N), or a fictitious-though-accurate no-op transition is inserted at time N. Either way, the data representing the transition at time N would then be correct. Therefore, it is certainly my understanding that such behavior is indeed required by RFC 8536. And yes, that is very much because it's nicer. -- Tim Parenti