[Bug 2150342] [NEW] date: width prefix in %N format specifier is ignored ( %3N, %6N always output full 9 nanosecond digits)

[Fumihito YOSHIDA]

Public bug reported:

This is difference about gnudate/date command behaviour about nanosecond
syntax.

The date format specifier "%N" supports an optional decimal-width prefix
with gnudate (e.g. %3N for milliseconds, %6N for microseconds) that
truncates the nanosecond string to the first N characters.

However uutils date ignores this prefix and always outputs all 9 digits
without warnings, it might break backward compatibility that rely on
date +%s%3N to obtain millisecond-resolution epoch timestamps.

[Steps to reproduce]
```
date +%3N   # expected: 3 digits; actual: 9 digits
date +%6N   # expected: 6 digits; actual: 9 digits
date +%s%3N # expected: 13-digit epoch-ms; actual: 19-digit epoch-ns
```

[Expected] (gnudate)
```
$ gnudate +%3N
111
$ gnudate +%6N
111935
$ gnudate +%T.%3N
10:00:39.110
$ gnudate +%s%3N
1777165239109
```

[Actual] (uutils date 0.8.0)
```
$ date +%3N
100952336
$ date +%6N
103515189
$ date +%T.%3N
10:00:39.97839160
$ date +%s%3N
177716523994933752
```

[Assumption]

GNU coreutils documents %N as:
```
%N — nanoseconds (000000000..999999999)
A leading decimal number specifies left-justified field width; e.g. %3N yields the first 3 digits (milliseconds).
```

uutils outputs 9 digits regardless of the width prefix. The width value
appears to be parsed and then discarded.

Note that %9N (full nanoseconds, no truncation needed) produces correct
output in both implementations.

[Typical workaround]
Replace date +%s%3N with date +%s%N and divide the difference by 1000000, like:

```
start=$(date +%s%N)
# ... work ...
elapsed=$(( ($(date +%s%N) - start) / 1000000 ))  # milliseconds
```

ProblemType: Bug
DistroRelease: Ubuntu 26.04
Package: rust-coreutils 0.8.0-0ubuntu3
ProcVersionSignature: Ubuntu 7.0.0-14.14-generic 7.0.0
Uname: Linux 7.0.0-14-generic x86_64
ApportVersion: 2.34.0-0ubuntu2
Architecture: amd64
CasperMD5CheckResult: pass
Date: Sun Apr 26 10:04:26 2026
InstallationDate: Installed on 2026-03-25 (32 days ago)
InstallationMedia: Ubuntu-Server 24.04.4 LTS "Noble Numbat" - Release amd64 (20260210)
ProcEnviron:
 LANG=ja_JP.utf8
 PATH=(custom, no user)
 SHELL=/bin/zsh
 TERM=tmux-256color
 XDG_RUNTIME_DIR=<set>
SourcePackage: rust-coreutils
UpgradeStatus: Upgraded to resolute on 2026-04-25 (1 days ago)

** Affects: rust-coreutils (Ubuntu)
     Importance: Undecided
         Status: New


** Tags: amd64 apport-bug resolute

** Summary changed:

- date: width prefix in %N format specifier is ignored — %3N, %6N always output full 9 nanosecond digits
+ date: width prefix in %N format specifier is ignored ( %3N, %6N always output full 9 nanosecond digits)

-- 
You received this bug notification because you are a member of Ubuntu
Foundations Bugs, which is subscribed to rust-coreutils in Ubuntu.
https://bugs.launchpad.net/bugs/2150342

Title:
  date: width prefix in %N format specifier is ignored ( %3N, %6N always
  output full 9 nanosecond digits)

Status in rust-coreutils package in Ubuntu:
  New

Bug description:
  This is difference about gnudate/date command behaviour about
  nanosecond syntax.

  The date format specifier "%N" supports an optional decimal-width
  prefix with gnudate (e.g. %3N for milliseconds, %6N for microseconds)
  that truncates the nanosecond string to the first N characters.

  However uutils date ignores this prefix and always outputs all 9
  digits without warnings, it might break backward compatibility that
  rely on date +%s%3N to obtain millisecond-resolution epoch timestamps.

  [Steps to reproduce]
  ```
  date +%3N   # expected: 3 digits; actual: 9 digits
  date +%6N   # expected: 6 digits; actual: 9 digits
  date +%s%3N # expected: 13-digit epoch-ms; actual: 19-digit epoch-ns
  ```

  [Expected] (gnudate)
  ```
  $ gnudate +%3N
  111
  $ gnudate +%6N
  111935
  $ gnudate +%T.%3N
  10:00:39.110
  $ gnudate +%s%3N
  1777165239109
  ```

  [Actual] (uutils date 0.8.0)
  ```
  $ date +%3N
  100952336
  $ date +%6N
  103515189
  $ date +%T.%3N
  10:00:39.97839160
  $ date +%s%3N
  177716523994933752
  ```

  [Assumption]

  GNU coreutils documents %N as:
  ```
  %N — nanoseconds (000000000..999999999)
  A leading decimal number specifies left-justified field width; e.g. %3N yields the first 3 digits (milliseconds).
  ```

  uutils outputs 9 digits regardless of the width prefix. The width
  value appears to be parsed and then discarded.

  Note that %9N (full nanoseconds, no truncation needed) produces
  correct output in both implementations.

  [Typical workaround]
  Replace date +%s%3N with date +%s%N and divide the difference by 1000000, like:

  ```
  start=$(date +%s%N)
  # ... work ...
  elapsed=$(( ($(date +%s%N) - start) / 1000000 ))  # milliseconds
  ```

  ProblemType: Bug
  DistroRelease: Ubuntu 26.04
  Package: rust-coreutils 0.8.0-0ubuntu3
  ProcVersionSignature: Ubuntu 7.0.0-14.14-generic 7.0.0
  Uname: Linux 7.0.0-14-generic x86_64
  ApportVersion: 2.34.0-0ubuntu2
  Architecture: amd64
  CasperMD5CheckResult: pass
  Date: Sun Apr 26 10:04:26 2026
  InstallationDate: Installed on 2026-03-25 (32 days ago)
  InstallationMedia: Ubuntu-Server 24.04.4 LTS "Noble Numbat" - Release amd64 (20260210)
  ProcEnviron:
   LANG=ja_JP.utf8
   PATH=(custom, no user)
   SHELL=/bin/zsh
   TERM=tmux-256color
   XDG_RUNTIME_DIR=<set>
  SourcePackage: rust-coreutils
  UpgradeStatus: Upgraded to resolute on 2026-04-25 (1 days ago)

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/rust-coreutils/+bug/2150342/+subscriptions