(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
