[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Old timestamps in the future?
From: |
Paul Smith |
Subject: |
Re: Old timestamps in the future? |
Date: |
Fri, 09 Dec 2022 09:18:41 -0500 |
User-agent: |
Evolution 3.46.1 (by Flathub.org) |
On Fri, 2022-12-09 at 14:59 +0100, Gisle Vanem wrote:
> A file dated '1. Jan. 1970, 00:20' is wrongly claimed to be in the
> future. Some wrap going on here or something wrong with the logic in
> 'remake.c'? But a file dated '1. Jan. 1970, 01:00' is
> accepted fine.
>
> Looking at e.g.'is_ordinary_mtime()' it seems a 'st_mtime' must
> be larger than some X-value to qualify as a valid timestamp.
> So the above 20 min on Windows is not enough to be accepted
> as "ordinary" (?)
I don't know how things work on Windows, plus you seem to be using
POSIX tools here so you must be using some Windows-based POSIX
facilities that you don't specify (Cygwin? MinGW? WSL?)
I cannot reproduce this behavior on my GNU/Linux system.
But, note that touch writes timestamps in the current timezone by
default. It could be that your timezone (which you also didn't
specify) makes a difference, when you are talking about timestamps
right at the edge of the epoch.
If you force UTC, for example:
$ TZ=UTC make
does it make a difference in behavior?
I recommend you choose 1970-01-02 instead of 1970-01-01, just to be
safe regardless of local time.
- Old timestamps in the future?, Gisle Vanem, 2022/12/09
- Re: Old timestamps in the future?,
Paul Smith <=
- Re: Old timestamps in the future?, Gisle Vanem, 2022/12/09
- Re: Old timestamps in the future?, Eli Zaretskii, 2022/12/09
- Re: Old timestamps in the future?, Edward Welbourne, 2022/12/09
- Re: Old timestamps in the future?, Paul Smith, 2022/12/09
- Re: Old timestamps in the future?, Edward Welbourne, 2022/12/09
- Re: Old timestamps in the future?, Gisle Vanem, 2022/12/09
- Re: Old timestamps in the future?, Edward Welbourne, 2022/12/09