Re: Old timestamps in the future?

[Edward Welbourne]

Gisle Vanem (9 December 2022 14:59) wrote:
> I have an issue with things like
>   touch --date="1970-01-01"
[snip]
> Invoking it a 2nd time, GNU-make warns:
>    gnumake: Warning: File 'test-file-2' has modification time 1,8e+19 s in 
> the future
>    gnumake: Nothing to be done for 'all'.
>    gnumake: warning:  Clock skew detected.  Your build may be incomplete.

A quick check in python tells me:
>>> float(1 << 64)
1.8446744073709552e+19
your 1.8e+19 is in fact approximately 2^{64}, strongly hinting at an
overflow in a 64-bit integral type.

MS's time_t is indeed 64-bit; and MS's time_t-related POSIX functions
don't support times before the start of 1970, i.e. negative time_t
values, so it is eminently plausible MS's time_t is a 64-bit unsigned
int.  (Those same functions also don't support times after something
like year 3000, but that's another story.)  So it seems eminently likely
that your touch has set the time-stamp to just a little bit "less than"
0.

Since time_t is measured from the start, *in UTC*, of the year 1970,
local time anywhere east of Greenwich at time_t = 0 was somewhat later
than the start of January 1st at that point.  So - depending on your
time-zone - 1970-01-01 00:20 local time may well be before time_t = 0,
hence "a little bit less than 0" and thus 1.8e19 seconds in the future.
I'm guessing you're living in a CET-zone country, so your 01:00 is in
fact time_t = 0 and fine, but your 00:20 is forty minutes earlier, so
1.8e19 seconds later.

So Paul's advice to not use Jan 1st 1970 is sound and should suffice to
solve your problem.

        Eddy.