Fwd: PROBLEM: tty devices with future timestamps

[Egmont Koblinger <egmont@gmail.com>]

(Sorry, resending to include the list)

> As for setting it in the
> future, I don't think that's what is happening here,

Let's forget the "knock the lower bits off" part, it's irrelevant.
For the sake of simplicity, let's just pick a timestamp where those
bits are unset to begin with (i.e. a second divisible by 8).

If you set the seconds to the current seconds, but leave the
nanoseconds intact, whatever non-zero value it has, there's a good
chance that this results in a future timestamp (up to almost 1 second
into the future), as demonstrated in the example in my first mail.

In other words:  If you look at the entire, fine-grained timestamp,
you don't knock the lower bits off.  You update the higher bits, knock
the *middle* bits off, and leave the lower bits intact.

> you are just
> comparing two things that can't be compared as they are not the same
> thing.

Could you please elaborate?  (We're not understanding each other, and
I'm not sure in which direction :-))

My expectation is:  If the kernel maintains the concept of "current
time" which (apart from rare special circumstances like settimeofday()
-- we're not talking about those) always grows, and maintains the
"last access timestamp" of files, it shouldn't be possible that the
automatically updated "last access timestamp" is bigger than the
"current time".

Is this a wrong expectation?  Because if so, then I guess I should
follow up with coreutils devs to reconsider how they decide -- based
on comparing these two values: the file's "last access timestamp" and
the "current time" -- which formatting to pick.  If this is what you
referred to by "comparing two things that can't be compared" then what
they do is conceptually wrong.

> as it needs to be fast.

Zeroing out the nanoseconds -- maybe just once, at tty creation -- is
fast, and eliminates the possibility of future timestamps.

(s/milli/nano in my previous mails)


cheers,
egmont