On Fri, Aug 21, 2026 at 03:25:10PM +0200, Vincent Lefevre wrote:
On 2026-08-21 11:20:26 +0200, Oswald Buddenhagen via Mutt-dev wrote:
also, i'd generally speak of precision rather than granularity. to me, the
former seems more suggestive of general fuzziness, which seems more fitting
here.
No, this is not the same thing. The mtime has had a nanosecond
precision for years. But the granularity changed recently.
and my language intuition says that this is just wrong.
Teh Bot says
https://chatgpt.com/share/6a893fa3-b1e4-83eb-a43d-f38fc2b1c2c0 which
seems to agree.
but when asked more specifically, it gets closer to your position:
https://chatgpt.com/share/6a8949c3-569c-83eb-a993-dc5e37be6960
so i think it's wise to avoid the use of "precision" here, and instead
use "accuracy".
using "granularity" is similarly unwise: the field's granularity
obviously didn't change. but the update granularity changed. notably,
that doesn't mean that the readings now strictly comply with a less
granular grid, as the updates can have some jitter. also, if the kernel
guys chose to avoid the problem by using my suggested fix, the update
granularity would be entirely non-deterministic from the coarse clock
user's perspective, while still being compatible with the clock's
objective. it's an implementation detail.
