bug#79113: du --time-styles inconsistencies between manual and behaviour

tag 79113 notabug
close 79113
stop

On 28/07/2025 15:44, Nicolas Boichat wrote:
> Hi,
> 
> Version: env du --version => du (GNU coreutils) 9.7
> OS: archlinux, x86-64
> 
> The GNU coreutils manual says
> (https://www.gnu.org/software/coreutils/manual/coreutils.html#index-_002d_002dtime_002dstyle-1):
> - "You can specify the default value of the --time-style option with
> the environment variable TIME_STYLE; if TIME_STYLE is not set the
> default style is ‘long-iso’." -> yes
> - "For compatibility with ls, if TIME_STYLE begins with ‘+’ and
> contains a newline, the newline and any later characters are ignored;"

Copying the full docs for this from the texinfo:

   "You can specify the default value of the @option{--time-style} option
   with the environment variable @env{TIME_STYLE}; if @env{TIME_STYLE} is not set
   the default style is @samp{long-iso}.  For compatibility with @command{ls},
   if @env{TIME_STYLE} begins with @samp{+} and contains a newline,
   the newline and any later characters are ignored; if @env{TIME_STYLE}
   begins with @samp{posix-} the @samp{posix-} is ignored; and if
   @env{TIME_STYLE} is @samp{locale} it is ignored."

That quite clearly states the above compat handling
is for the TIME_STYLE env var, and not the --time-style option itself.

> 
> That does not match behaviour, newlines are just used as-is:
> ```
> $ env du --time --time-style="$(printf "+xyz\nabc")" blob
> 96 xyz
> abc blob
> ```

> Finally, the help text doesn't mention that +FORMAT is allowed.

Copying from the texinfo again:

   "List timestamps using @var{format}, where @var{format} is interpreted
   like the format argument of @command{date} (@pxref{date invocation}).
   For example, @option{--time-style="+%Y-%m-%d %H:%M:%S"} causes
   @command{du} to list timestamps like @samp{2020-07-21 23:45:56}.  As
   with @command{date}, @var{format}'s interpretation is affected by the
   @env{LC_TIME} locale category."

thanks,
Padraig