Bug 276918

Summary: "zpool status -t": output is inconsistent
Product: Base System Reporter: Maxim Filimonov <che>
Component: binAssignee: freebsd-fs (Nobody) <fs>
Status: Closed Overcome By Events    
Severity: Affects Only Me CC: emaste, vvd
Priority: ---    
Version: 14.0-STABLE   
Hardware: Any   
OS: Any   

Description Maxim Filimonov 2024-02-09 10:44:22 UTC
I'm using FreeBSD stable/14, and I noticed the following:
When using the Russian UTF-8 locale, here's what "zpool status -t" gives me:

% zpool status -t
  pool: zroot
 state: ONLINE
  scan: scrub repaired 0B in 00:09:42 with 0 errors on Fri Feb  9 14:11:58 2024
config:

        NAME          STATE     READ WRITE CKSUM
        zroot         ONLINE       0     0     0
          nda0p4.eli  ONLINE       0     0     0  (100% trimmed, completed at пятница,  9 февраля 2024 г. 14:28:37)

errors: No known data errors


Note it says scrub has been completed at a certain point in time in English, but then it says trim has been completed at a certain point in time in Russian.

I suppose, the dates should be printed in English in both cases.

Here's a bit more info:
% uname -rsm
FreeBSD 14.0-STABLE amd64
% locale
LANG=ru_RU.UTF-8
LC_CTYPE="ru_RU.UTF-8"
LC_COLLATE="ru_RU.UTF-8"
LC_TIME="ru_RU.UTF-8"
LC_NUMERIC="ru_RU.UTF-8"
LC_MONETARY="ru_RU.UTF-8"
LC_MESSAGES="ru_RU.UTF-8"
LC_ALL=
Comment 1 Vladimir Druzenko freebsd_committer freebsd_triage 2024-02-09 13:18:45 UTC
1st part:
src/sys/contrib/openzfs/cmd/zpool/zpool_main.c (print_scan_scrub_resilver_status):
> end = ps->pss_end_time;> (void) printf(gettext("scrub repaired %s "
>    "in %s with %llu errors on %s"), processed_buf,
>    time_buf, (u_longlong_t)ps->pss_errors,
>    ctime(&end));

2nd part:
src/sys/contrib/openzfs/cmd/zpool/zpool_main.c (print_status_trim):
> (void) localtime_r(&t, &zaction_ts);
> (void) strftime(tbuf, sizeof (tbuf), "%c", &zaction_ts);> (void) snprintf(zbuf, sizeof (zbuf), ", %s %s",
>     gettext("completed at"), tbuf);

I think localtime_r + strftime do this.

IMHO, it's better to ask OpenZFS upstream to change this behavior.
Comment 2 Ed Maste freebsd_committer freebsd_triage 2024-02-09 19:29:11 UTC
> IMHO, it's better to ask OpenZFS upstream to change this behavior.

Yes, that is the best course of action.
Comment 3 Maxim Filimonov 2024-02-10 16:14:13 UTC
Here's the issue with OpenZFS GitHub: https://github.com/openzfs/zfs/issues/15878
Here's the pull request: https://github.com/openzfs/zfs/pull/15879