From: Crystal Kolipe Subject: Re: mtime format in ls -l To: Ingo Schwarze Cc: tech@openbsd.org, Jan Stary , sthen@openbsd.org Date: Sun, 18 Jan 2026 17:22:43 +0000 Hi Ingo, On Sun, Jan 18, 2026 at 04:21:21PM +0100, Ingo Schwarze wrote: > Anyway, the question to ask is: will the entry be useful for a > significant number of readers of this manual page? > > The most plausible reason for looking at the ls(1) manual is the > desire to inspect some properties of some files (in particular > more unusual properties, or in unusual ways). But almost all > properties of files *can* be inspected with ls(1) - there are > very few that stat(1) can show but ls(1) cannot: > > * st_dev, the device number - > irrelevant because it's the same for the whole file system > * st_rdev for non-device files - > irrelevant because it has no meaning > * st_blksize - if i understand correctly, > irrelevant because it's the same for the whole file system > * st_blocks, the number of blocks allocated > * st_birthtime, st_gen - my impression is OpenBSD does not support these(?) > > So the only property that could (maybe) matter appears to be st_blocks - > but the probability of someone looking at ls(1) because they want to > inspect that field feels very low, making the benefit of adding stat(1) > to ls(1) SEE ALSO very small. > > On the other hand, there is a minor downside to adding it. > While stat(1) does not sport a STANDARDS section and the HISTORY > section makes it quite apparent that it is unlikely to be particularly > portable, that is easy to overlook, in particular when getting there > from a place as prominent as the manual of the POSIX ls(1) command, > so such a link could incite people to lower portability of whatever > they are doing without even becoming aware of the issue. > > So i'm mildly opposed to adding stat(1) to ls(1) SEE ALSO, > unless someone can convince me what stat(1) can provide that > readers of ls(1) might be looking for. The common reason for preferring stat over ls is in getting timestamps in a format that can be reliably parsed in scripts. The original post in this thread was talking about the date format of ls -l, which is basically this: -rw-r--r-- 1 root wheel 0 Jan 18 16:29 file_1 -rw-r--r-- 1 root wheel 0 Jan 1 1970 file_2 Due to the year field being shared with the hours and minutes field, depending on how old the file is, parsing this from a script is tedious and inaccurate. (Side note - portable scripts might even have to deal with the month being represented in a languge other then English on non OpenBSD systems.) Using -T improves the situation somewhat: -rw-r--r-- 1 root wheel 0 Jan 18 16:29:32 2026 file_1 -rw-r--r-- 1 root wheel 0 Jan 1 00:00:00 1970 file_2 This is somewhat easier to parse with a script, but there is a caveat - the times printed by ls are relative to the current timezone. If your timezone changes, the output from ls -lT changes too. If the system is configured for a timezone which includes DST rules, then the output from ls -lT can change from one run to the next even for files which have not been touched. On the other hand, stat can be told to report absolute times since the epoch, with no adjustment for local timezone: # export TZ=/usr/share/zoneinfo/Factory # ls -lT ; stat -f '%N %a' * total 0 -rw-r--r-- 1 root wheel 0 Jan 18 16:29:32 2026 file_1 -rw-r--r-- 1 root wheel 0 Jan 1 00:00:00 1970 file_2 file_1 1768753772 file_2 0 # export TZ=/usr/share/zoneinfo/Etc/GMT-12 # ls -lT ; stat -f '%N %a' * total 0 -rw-r--r-- 1 root wheel 0 Jan 19 04:29:32 2026 file_1 -rw-r--r-- 1 root wheel 0 Jan 1 12:00:00 1970 file_2 file_1 1768753772 file_2 0 Note that the output from stat does not change. So basically script writers who are trying to parse timestamps read from ls because they are unaware of stat are who would potentially benefit from a mention in ls(1). Admittedly that might be a small audience, but I can imagine that it might avoid some overly complicated or buggy scripts being written.