Hello,
First, thank you for maintaining and developing this ambitious project!
TL;DR: the output of date -d0 is different from the GNU version, which is different from the busybox version.
-
coreutils date -d0
Fri Dec 31 22:17:30 LMT -0001
-
/usr/bin/gnudate -d0
Mon 13 Oct 00:00:00 CEST 2025
-
busybox date -d0
date: invalid date '0'
To be honest, when looking at the man page, I don't know who is right and who is wrong. But the GNU manual describes this behaviour, so I guess the Rust version should do the same, and parse decimal numbers of the form hhmm or just hh as hours and minutes from the current day, no?
(Note: With the Rust version, I don't know why we have this output, but the +%s version gives -62167226399. FYI, when I feed this to the GNU version (/usr/bin/gnudate -d"@-62167226399"), we get almost the same output: Fri 31 Dec 22:17:31 LMT -001, one-second difference ; is it normal? Should I create another issue)
On my side, the exact value for this doesn't really matter, but when using the Rust's date version, I have issues when building the Linux kernel:
$ KBUILD_BUILD_TIMESTAMP="0" make
(...)
ERROR: Timestamp out of range for cpio format
make[4]: *** [usr/Makefile:76: usr/initramfs_data.cpio] Error 1
make[4]: *** Deleting file 'usr/initramfs_data.cpio'
make[3]: *** [scripts/Makefile.build:556: usr] Error 2
make[3]: *** Waiting for unfinished jobs....
I have this issue, because date -d"0" +%s is used, and returns an unsupported negative value.
There are different workarounds (KBUILD_BUILD_TIMESTAMP="-1" or disabling CONFIG_BLK_DEV_INITRD), but I guess the issue should be fixed on uutils' coretutils side, and not adding a special case in the Linux kernel build system to avoid negative values, right?
Hello,
First, thank you for maintaining and developing this ambitious project!
TL;DR: the output of
date -d0is different from the GNU version, which is different from the busybox version.To be honest, when looking at the man page, I don't know who is right and who is wrong. But the GNU manual describes this behaviour, so I guess the Rust version should do the same, and parse decimal numbers of the form
hhmmor justhhas hours and minutes from the current day, no?(Note: With the Rust version, I don't know why we have this output, but the
+%sversion gives-62167226399. FYI, when I feed this to the GNU version (/usr/bin/gnudate -d"@-62167226399"), we get almost the same output:Fri 31 Dec 22:17:31 LMT -001, one-second difference ; is it normal? Should I create another issue)On my side, the exact value for this doesn't really matter, but when using the Rust's date version, I have issues when building the Linux kernel:
I have this issue, because
date -d"0" +%sis used, and returns an unsupported negative value.There are different workarounds (
KBUILD_BUILD_TIMESTAMP="-1"or disablingCONFIG_BLK_DEV_INITRD), but I guess the issue should be fixed on uutils' coretutils side, and not adding a special case in the Linux kernel build system to avoid negative values, right?