Proposed magic number patch

Nathan Myers ncm at
Wed Oct 8 20:23:49 UTC 1997

John Cowan wrote:
> Chris Newman wrote:
> > Excellent idea, but I'd suggest choosing a magic number based on the
> > principles outlined in RFC 2083 section 12.11.  I propose:
> > 
> > \211 T Z \r \n ^Z \n
> > 
> > as a magic number.
> Thanks for the reference to RFC 2083.  I have two problems:
> 1)	7 bytes is a "peculiar" length.  I suggest adding a NUL
> 	(\0) byte just after the Z, if we go with this scheme.
> 	In which case "strncpy" will have to be replaced with
> 	"memcpy".
> 2)	There are only 20 available bytes.  I am a little
> 	reluctant to consume 8 of them, leaving at most 3
> 	new 32-bit length quantities.  Consuming only 4
> 	is less risky.

I agree that seven bytes is a bit long.  PNG format files suffer
indignities that I don't think the TZ records need to defend against.
I don't know why "^T ^Z" would be insufficient.  In addition, 
though, I'd like to see a version sequence number too, so that 
if the less-than-20 bytes of slop remaining prove insufficient, 
we have a recourse.

I maintain that advisory timestamps:

 - when the information was entered
 - when the information was last known to be current
 - when the information will no longer be officially trustworthy
   (24 hours later, by default)
 - when the local installation will no longer consider the 
   information current (perhaps longer, perhaps shorter, by preference)

would be a useful addition to the format, in support of incremental
network caching.  Of course, we should also move to a 64-bit external
time representation as soon as possible, which would also be the first
increment of the version sequence number.

Nathan Myers
ncm at

More information about the tz mailing list