-----邮件原件----- 发件人: Paul Eggert [mailto:eggert@xxxxxxxxxxx] 发送时间: 2018年9月27日 23:38 收件人: Qin Wu; ops-dir@xxxxxxxx 抄送: draft-murchison-tzdist-tzif.all@xxxxxxxx; ietf@xxxxxxxx; 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? 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 would suggest to make this clear since you are using "32-bit transitions", 32 bit transition is equivalent to a multiple of 32-bit? No A leap second record is 8 octets in the 32-bit data block, and is 12 octets in the 64-bit data block. The difference in length is because the former uses a 4 octet 'occur' field whereas the latter uses 8. The 'corr' field is always a 4-octet value, because it's assumed that the leap second correction (which is a relative time, not an absolute time) must fit into a 32-bit signed integer. In hindsight perhaps the leap second correction should also have been an 8-octet value, as the 4-octet value will stop working many thousands of years from now (see <https://www.ucolick.org/~sla/leapsecs/dutc.html> for why) whereas an 8-octet value would have been more future-proof. However, billions of readers already assume 4-octet leap second corrections so we'll have to defer fixing this to a later version of TZif. Most likely version 3 will be obsolete for other reasons long before the limited 'corr' range becomes a real problem. (If you think this issue should be discussed in the spec, I can add something; just let me know.) The attached proposed patch assumes an earlier patch <https://www.ietf.org/mail-archive/web/tzdist-bis/current/msg00339.html> that I proposed in response to Tom Petch's review.
