Hi, An active terminal line (/dev/pts/N), in about 6% of the cases, has a future timestamp. I noticed that the command ls -l $(tty) occasionally prints the timestamp in "month day year" format, rather than "month day hour:minute". This is what coreutils's "ls" does when the timestamp is either 6+ months back in the past, or is in the future. Let's test the "in the future" hypothesis: ls -l --full-time $(tty); date +%H:%M:%S.%N occasionally produces something like crw--w---- 1 egmont tty 136, 8 2020-06-27 09:57:28.686473296 +0200 /dev/pts/8 09:57:28.170717548 Yep, the timestamp of the tty line is a slightly higher value than the system date at a later point. Running ls -l --full-time $(tty) in an endless loop causes the seconds to increment in steps of 8, but the subseconds part remains unchanged, like: crw--w---- 1 egmont tty 136, 8 2020-06-27 10:07:12.686473296 +0200 /dev/pts/8 crw--w---- 1 egmont tty 136, 8 2020-06-27 10:07:12.686473296 +0200 /dev/pts/8 crw--w---- 1 egmont tty 136, 8 2020-06-27 10:07:20.686473296 +0200 /dev/pts/8 crw--w---- 1 egmont tty 136, 8 2020-06-27 10:07:20.686473296 +0200 /dev/pts/8 drivers/tty/tty_io.c : tty_update_time() seems to be responsible for this jump in 8 seconds, leaving the milliseconds intact. I think zeroing out the milliseconds in this method would solve the problem – although then it's maybe inconsistent that at creation time the device would have subsecond precision which would be gone soon afterwards. Maybe it's better to create the device with no subseconds right away? I'll leave it to you guys to decide. I'm experiencing this on two different machines with Ubuntu 20.04, using their 5.4.0 kernel. The method setting the seconds but not the nanoseconds is still present in latest kernel git. Thanks a lot, egmont
