Re: [Tzdist-bis] Opsdir last call review of draft-murchison-tzdist-tzif-14

[Paul Eggert <[e-mail]>]

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. 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.