On 9/27/18 7:42 PM, Qin Wu wrote:
-----邮件原件-----
发件人: Paul Eggert [mailto:eggert@xxxxxxxxxxx]
发送时间: 2018年9月27日 23:38
收件人: Qin Wu; ops-dir@xxxxxxxx
抄送: draft-murchison-tzdist-tzif.all@xxxxxxxx; ietf@xxxxxxxxx; Ken Murchison; tzdist-bis@xxxxxxxx
主题: Re: Opsdir last call review of draft-murchison-tzdist-tzif-14
Thanks for the review. Attached is a proposed patch that attempts to address your comments, except that I didn't understand this remark:
3.Leap second records definition
How 64 bit data block can be used to accommodate 16 octet records?
The draft doesn't mention 16-octet records, so I'm not sure what this comment is referring to.
[Qin]: My bad, it is a 12-octets records, however I am not sure how 64bit data block can accommodate 96bit (i.e.,12 octets), is data block length 64 bit or a multiple of 64 bit, I think it is the latter, right?
The data block length is not necessarily a multiple of 64 bits (8
octets). The data block can therefore easily accommodate 12-octet
records. The time zone designations part of the data block even
accommodates 1-octet records.
Still in the figure for General Format of TZif Files, header for 32-bit transitions and Data for 32-bit transitions are not clear to me, since the header length is 44 octets, the data block length is a multiple of 32-bit
I don't see anything in the figure implying that the data block length
is a multiple of 32 bits. To avoid confusion, we could append to the
following NOTE some text that says "Headers, blocks, the footer, and
their components are not aligned or padded; for example, an eight-octet
time value can appear at an odd offset from the start of the data."
I would suggest to make this clear since you are using "32-bit transitions", 32 bit transition is equivalent to a multiple of 32-bit?
Each 32-bit transition time is indeed 32 bits and is represented by 4
octets. However, these octets are not aligned to be on a 4-octet
boundary. I hope the abovementioned proposed addition clears up any
confusion in this area.
