default in GNU tar header may cause warnings

[0-wiz-0]

The orjson tarballs have a couple of files that have a timestamp of Jan 1, 1970.
Some tar(1) versions complain about this, since it often points to corruption in the tar file.

Example output:

gtar: orjson-3.10.16/include/pyo3/pyo3-ffi/Cargo.toml: implausibly old time stamp 1970-01-01 00:00:00
gtar: orjson-3.10.16/include/pyo3/pyo3-build-config/Cargo.toml: implausibly old time stamp 1970-01-01 00:00:00
gtar: orjson-3.10.16/Cargo.toml: implausibly old time stamp 1970-01-01 00:00:00

In https://github.com/ijl/orjson/issues/566 I was told that this behaviour comes from maturin.

In PyO3/maturin#2576 I was told this comes from the tar crate.

I'm not sure if this crate should change the default or not, but I thought I'd mention it.

[xzfc]

From my search, this message came from old versions of GNU Tar. Starting from GNU Tar 1.27 (released in October 2013), it doesn't produce a warning when sees UNIX timestamp 0. (mailing list thread, commit)

Also, relevant: when HeaderMode::Deterministic is enabled, filesystem timestamps for files added by Builder are ignored, and Jul 23, 2006 is used instead. Applies to methods accessing the filesystem, but not to, e.g., Builder::append_data. (PRs #250, #262)

Perhaps, Header::new_gnu could use the same timestamp instead of 0. However, for this constructor, I feel that 0 is more sensible default than arbitrary recentish timestamp. And in the worst case we'll get a warning (not an error) in 11+ years old GNU Tar versions. If it's an issue, an application developer should set mtimes explicitly.

---

In short, I suggest to keep it as is.