Date rejects valid large years that GNU date accepts

[sylvestre]

GNU:

  $ LANG=C TZ=UTC0 /usr/bin/date -d "18978-01-01"
  Thu Jan  1 00:00:00 UTC 18978

Rust:

  $ LANG=C TZ=UTC0 ./target/debug/date -d "18978-01-01"
  date: invalid date '18978-01-01'

• GNU date: Accepts year 18978 and outputs the date correctly
• Rust date: Rejects year 18978 as invalid date, appears to have a limit around year 9999
• GNU date supports much larger year ranges than our implementation

Found with a fuzzer

[cakebaker]

See also uutils/parse_datetime#160

[n22arora]

can I work on this?

[cakebaker]

@n22arora sure, go ahead! However, I'm not sure whether this is a good first issue as it looks like it's a limitation of the library we use :|

[SamuelAyibatarri]

As @cakebaker correctly stated, the problem is from the library, my logs: DEBUG: Received date string: "18979-01-01"

x@debian:~/Desktop/projects/coreutils$ ./target/debug/date -d "18979-01-01"
DEBUG: Tried converting date to string: Some("18979-01-01")
DEBUG: This 'parse_date' function
DEBUG: [parse_date] -> input_str: "18979-01-01"
DEBUG: [parse_date] -> Passed the first if statement (dbg_opts.debug)
DEBUG: [parse_date] -> Passed the second if statement, if this run it means there were no errors in the if statement above
DEBUG: [parse_date] -> Inside the match Err statement. Error: InvalidInput
date: invalid date '18979-01-01'

I'll attempt to find the exact cause of the issue and try to fix it.

[abhishekpradhan]

Hello! I looked into this, and the root cause turned out to be in parse_datetime.

That fix has now been merged in uutils/parse_datetime#263.

The coreutils side is in #10931. That updates date and touch to handle out-of-range years, and adds coverage for formatting, offsets, and far-future timezone behavior.

For now, #10931 is pinned to the parse_datetime 0.15.0 git tag, since that version has been tagged upstream but has not been published on crates.io yet.

[SamuelAyibatarri]

Good work!