I don't think there's a right answer here. The current logic is entirely reasonable as it optimizes for accuracy at the cost of occasionally being in the future for 500ms. The suggested logic is 500ms less accurate, but avoids being in the future. Both are reasonable and I don't think it's a compelling reason to change, since this will probably break many use-cases that have come to depend on archive/tar for deterministic outputs (see Hyrum's Law).

Have you considered using FormatPAX? That supports high-precision timestamps and may entirely avoid this problem. Also, whatever is flagging archives from the future should probably tolerate an error on the same order as the smallest representable time unit (1s in this case).

this will probably break many use-cases that have come to depend on archive/tar for deterministic outputs (see Hyrum's Law).

yepp, api consumers hate surprises

its just unexpected behavior, cos usually float-to-int casts mean rounding down

Have you considered using FormatPAX? That supports high-precision timestamps and may entirely avoid this problem.

workaround in ipfs: pass integer time to archive/tar

 func writeFileHeader(w *tar.Writer, fpath string, size uint64) error {
 	return w.WriteHeader(&tar.Header{
 		Name:     fpath,
 		Size:     int64(size),
 		Typeflag: tar.TypeReg,
 		Mode:     0644,
-		ModTime:  time.Now(),
+		ModTime:  time.Now().Truncate(time.Second),
 	})
 }

whatever is flagging archives from the future should probably tolerate an error on the same order as the smallest representable time unit (1s in this case).

yes. in this case nixos unpackFile → _defaultUnpack → tar xf "$fn"
this should be tar xf "$fn" --warning=no-timestamp

thanks! : )

closing

That seems like an entirely reasonable and easy workaround.