Comment 1:

Labels changed: added priority-soon, packagebug, removed priority-triage.

Owner changed to @dsymonds.

Status changed to Accepted.

Comment 2:

The problem is that a zero ModTime gives a large negative t.Unix() value, which confuses
everything. I'll avoid writing a mod time outside the specified range.

Status changed to Started.

Comment 3:

I think the same problem will affect other numeric fields, such as Size. Wouldn't it be
better to modify Reader.octal, or add a new Reader.numeric function, to decode the
binary value if the most significant bit is set?
If you do add extra checks to the Writer, I suggest you also return ErrFieldTooLong when
len(Header.Name) > 100. Until support is added for longer file names, it's better to
report an error instead of silently truncating the value.

Comment 4:

The other fields, I believe, have plenty of space for the range of values permitted by
their fields. Bigger numbers already switch to the binary format if required. ModTime is
the problematic one because its use of .Unix() yields a negative number that is not even
supported by most tars.
However, you are right that Reader does not support the binary format at all. That would
be the other half of this issue.

Comment 5:

This issue was updated by revision 0ac3178.

Still to do: support binary numeric format in Reader.
R=golang-dev, rsc
CC=golang-dev
http://golang.org/cl/6818101

Comment 6:

This issue was closed by revision 86b9e3e.

Status changed to Fixed.