#114229 Shouldn't complain about timestamps in the future

Package:
tar
Source:
tar
Description:
GNU version of the tar archiving utility
Submitter:
"M. Hari Nezumi"
Date:
2025-06-03 13:07:02 UTC
Severity:
wishlist
#114229#5
Date:
2001-10-02 18:26:01 UTC
From:
To:
I synchronize my computer's clock to an NTP server.  When I create a tar file,
it puts on my local timestamp.  Then I decompress the same tar file on another
machine (using tar xvpf, since I want to preserve the file permissions, which
IMO should be done by default, but that's another matter).  The machine I
extract it on syncs to an NTP server which is a few minutes behind.  So when I
extract the tar file, I get a whole bunch of errors like:

tar: public_html/gallery/audio/fp/fans.html: time stamp 2001-10-02 11:12:33 is 127 s in the future

which is very annoying. :)  It also gets in the way of me seeing any *real*
errors which may have occurred.

Basically, it'd be nice if it didn't complain about future timestamps like
that, or if it only complained once per archive or something.

#114229#10
Date:
2001-10-02 21:41:53 UTC
From:
To:
magenta@trikuare.cx (M. Hari Nezumi) writes:

Of course, the notion that a server using NTP could be "a few minutes behind"
is pretty bad...  Probably worth getting fixed regardless of how tar behaves.

Bdale

#114229#15
Date:
2001-10-02 22:18:42 UTC
From:
To:
Yeah, of course, but that's besides the point.  What about a machine which
is just getting set up and doesn't have ntpd on, for example?  IMO,
absolute system time is one of those things which shouldn't be relied on to
an extreme.  Obviously, it's very useful for stuff (such as triggering at
or cron events), and to an extent the well-ordered nature of relative time
as well (though of course NTP updates can still cause problems, and of
course there's always the potential for relativistic effects due to
travelling at very high relative velocities).

Also, there's other situations where the time can be "correct" but have
different epoch-based timestamps, for example if the timezone is set
incorrectly.  The local time appears correct (aside from the timezone), but
the UTC time is not.

Philosophy aside, it's still really annoying to get a warning on every
single file, and it really shouldn't warn more than once, preferrably
deferred to the end... I like how Make handles it - it waits until the end
of the build cycle and then says, "By the way, clock skew was detected."  I
see no reason to put the warning on every file.

#114229#20
Date:
2025-06-03 12:55:48 UTC
From:
To:
Dear M. Hari Nezumi,
Your report is quit old. Maintainers comment on it but did not take any
action (e.g. closing).
Time has passed and version at upstream increased.

Please check if the issue you describe is still relevant in the latest
version provided by Debian GNU/Linux.

It seems to me that the issue might better located at the upstream
project. I suggest to ask on their mailing list before opening a bug
ticket.

     <https://www.gnu.org/software/tar/>

Regards,
Christian Buhtz