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?