Date command behaviour different between 24.04 and 26.04

Support and Help
, ,
1

Ubuntu Support Template

Ubuntu Version:
26.04 LTS
24.04 LTS
Desktop Environment (if applicable):
GNOME

Problem Description:
commend “date +%s%1N” does not return the same output if run on ubuntu26.04 LTS or ubuntu24.04 LTS

ubuntu24.04$ epoch=$(date +%s%1N) && echo $epoch 
17780487469

ubuntu26.04$ epoch=$(date +%s%1N) && echo $epoch 
1778048526586738292

is this normal/documented somewhere?
how can I achieve the same behavior?
man date on ubuntu 26 is lighter than in ubuntu24…

thank you for your help
Gérald

2

Probably a bug? To me this looks like the field width of nanoseconds is simply ignored on Ubuntu 26.04. Or maybe field width is now interpreted as minimum width? Are you using rust-coreutils? Maybe this is related to ‘oxidizing’ corutils?
According to man pages, both (noble, resolute) should support field width (questing is different). What does your local man page say?

[edit]
Line 26 of source file format_modifiers.rs reads ‘One or more digits specifying minimum field width’. So if you are using rust-corutils this behaviour is as expected (and to me makes totally sense). You may test this by increasing the field with above 9 (‘nano’).

3

on ubuntu 26.04 LTS (and on 24.04 LTS too), I use the default date command. According to man date, version is v(uutils coreutils) 0.8.0

on 26.04, the date manual is copied below…but not really helpful

DATE(1)                                                             General Commands Manual                                                             DATE(1)
NAME
       date - Print or set the system date and time
SYNOPSIS
       date  [-d|--date]  [-f|--file]  [-I|--iso-8601]  [--resolution]  [-R|--rfc-email]  [--rfc-3339]  [--debug]  [-r|--reference] [-s|--set] [-u|--universal]
       [-h|--help] [-V|--version] [format]
DESCRIPTION
       Print or set the system date and time
OPTIONS
       -d, --date <STRING>
              display time described by STRING, not 'now'
       -f, --file <DATEFILE>
              like --date; once for each line of DATEFILE
       -I, --iso-8601 [<FMT>]
              output date/time in ISO 8601 format.  FMT='date' for date only (the default), 'hours', 'minutes', 'seconds', or 'ns' for date and time to the in‐
              dicated precision.  Example: 2006-08-14T02:34:56-06:00
              Possible values:
                     • date
                     • hours
                     • minutes
                     • seconds
                     • ns
       --resolution
              output the available resolution of timestamps Example: 0.000000001
       -R, --rfc-email
              output date and time in RFC 5322 format.  Example: Mon, 14 Aug 2006 02:34:56 -0600
       --rfc-3339 <FMT>
              output date/time in RFC 3339 format.  FMT='date', 'seconds', or 'ns'  for  date  and  time  to  the  indicated  precision.   Example:  2006-08-14
              02:34:56-06:00
              Possible values:
                     • date
                     • seconds
                     • ns
       --debug
              annotate the parsed date, and warn about questionable usage to stderr
       -r, --reference <FILE>
              display the last modification time of FILE
       -s, --set <STRING>
              set time described by STRING
       -u, --universal
              print or set Coordinated Universal Time (UTC)
       -h, --help
              Print help
       -V, --version
              Print version
       [format]
VERSION
       v(uutils coreutils) 0.8.0
2026-04-16                                                                   DATE(1)
4

Looks like default date command in 26.04 has been changed to rust-coreutils.

5

quite annoying this modification of behavior…

so it seems there is no way to have the same behavior in rust-coreutils and in GNU coreutils
I will have to substring the date +%s%N to obtain what I had on ubuntu 24

6

Maybe you can switch to gnu-coreutils.

AI answer (!) to ‘how to use gnu-coreutils on ubuntu 26.04’ (didn’t test this myself!):

sudo apt update
sudo apt install gnu-coreutils
sudo update-alternatives --set coreutils /usr/bin/gnu-coreutils
7

I changed my script instead to be compatible on both versions whatever the utils are used…but strange the behavior differs

1 Like
8

According to upstream policy, it’s a bug, when output differs from GNU coreutils. The issue seems to have been fixed, but only very recently. And this is the Launchpad bug to go with it.

2 Likes
9

ok, thank you for the links!

1 Like
10

FWIW, you may also want to have a look at the release notes specific to rust-coreutils, which contains instructions to switch between GNU coreutils and rust-coreutils. But I think that might be unnecessary, since you have a workaround in place already.

1 Like
11

This topic was automatically closed 18 hours after the last reply. New replies are no longer allowed.