Edward Welbourne wrote:
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).
Thanks for the detailed explanation. Yes, it's rather confusing
with such
Paul Smith (9 December 2022 16:22) wrote:
> That's probably why it works on my system even though I'm at UTC-0500.
oh, and: that means you're west of Greenwich, so the epoch is your local
time 1969-12-31 19:00, so your 1970-01-01 00:00 is firmly in positive
time_t. So you had no chance of
On Fri, 2022-12-09 at 15:06 +, 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
On Fri, 2022-12-09 at 15:06 +, 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
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'.
>
> From: Gisle Vanem
> Date: Fri, 9 Dec 2022 15:38:08 +0100
>
> Paul Smith wrote:
>
> > ... facilities that you don't specify (Cygwin? MinGW? WSL?)
>
> I'm using Cygwin as my POSIX toolbox.
>
> > But, note that touch writes timestamps in the current timezone by
> > default. It could be that
Paul Smith wrote:
... facilities that you don't specify (Cygwin? MinGW? WSL?)
I'm using Cygwin as my POSIX toolbox.
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
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
I have an issue with things like
touch --date="1970-01-01"
(or 'touch -t time') that I sometime use in makefiles.
E.g. in this makefile:
-
all: test-file-1 test-file-2
test-file-1:
echo 'whatever' > $@
touch -t 197001010100 $@ # Jan 1. 1970,
