I have three questions about the format of the binary files. 1. Re the array of tzh_timecnt transitions: my kneejerk reaction was to think that these were similar to the values in the UNTIL column in the source files, in which case they'd be open upper bounds (in other words, the struct ttinfo that they eventually link to would be for the period immediately before the transition); but it occurs to me that they might be closed lower bounds instead (the corresponding ttinfo is for the period after the transition). tzfile(5) doesn't say explicitly. 2. Basically the same question for the array of leap seconds. The reason it occurs to me that the time_t value could be the point after the leap second is that that's the way that the USNO’s list of leap seconds works. 3. Re the version-'2' array of leap seconds: each array element is a time_t value followed by a count of the number of leap seconds after that time. tzfile(5) says that eight bytes are used for each "transition time" and "leap second time"; but since the count of leap seconds is neither of those, is the count still just four bytes? (I'm thinking that I can't just have a two-dimensional array of int64_t, but rather need a one-dimensional array of struct { int64_t, int32_t }. Is that right?) Thanks, --Bill Seymour
Bill Seymour wrote:
it occurs to me that they might be closed lower bounds instead (the corresponding ttinfo is for the period after the transition).
Yes, I think that's right.
tzfile(5) doesn't say explicitly.
It should. Proposed patch attached.
2. Basically the same question for the array of leap seconds.
tzfile(5) says it's the leap second count "to be applied after the given time". Seems reasonably clear but I suppose it could be tightened up. See attached patch.
3. Re the version-'2' array of leap seconds: each array element is a time_t value followed by a count of the number of leap seconds after that time. tzfile(5) says that eight bytes are used for each "transition time" and "leap second time"; but since the count of leap seconds is neither of those, is the count still just four bytes?
Yes it is. Arguably this is a defect, as the total leap second count (assuming the current rules) will greatly exceed 2**32 before 64-bit time_t values are exhausted. However, almost surely we'll change our timekeeping practices well before that happens, so the defect doesn't really matter much.
participants (2)
-
Bill Seymour -
Paul Eggert