Re: Old timestamps in the future?

[Edward Welbourne]

On Fri, 2022-12-09 at 15:06 +0000, Edward Welbourne wrote:
>> 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.

Paul Smith (9 December 2022 16:22)
> Interestingly on GNU/Linux, in glibc, you can provide negative time_t
> values [1] and correctly represent times earlier than the epoch.
> That's probably why it works on my system even though I'm at UTC-0500.
>
> [1] https://www.gnu.org/software/libc/manual/html_node/Time-Types.html

Indeed, on Unix, time_t is signed and modern GLibc / Linux functions
using it are perfectly happy with values across the whole range of the
type (which extends to well before the big bang).

The other possibility is that MS's time_t is signed but, because its
functions don't support negative values for it, some part of the system
gets an error from them and then, when reporting the issue, fetches the
(small negative, so "invalid") time-stamp into an unsigned 64-bit type
making the error a glitch in whatever is reporting the issue.

        Eddy.