Large year values are not parsed correctly

[Maximkaaa]

If the year value is larger then 9999, the parsing result is inconsistent with GNU implementation:

Input: 10000-12-31
GNU: 10000-12-31 00:00:00+00:00
parse_datetime: 0000-12-31 00:00:00+00:00

Input: 100000-12-31
GNU: 100000-12-31 00:00:00+00:00
parse_datetime: 2000-12-31 00:00:00+00:00

Input: 1000000-12-31
GNU: 1000000-12-31 00:00:00+00:00
parse_datetime: 0000-12-31 00:00:00+00:00

Input: 10000000-12-31
GNU: 10000000-12-31 00:00:00+00:00
parse_datetime: Invalid input string: cannot be parsed as a relative time

Input: 2147485547-12-31
GNU: 2147485547-12-31 00:00:00+00:00 // This is the max value supported by GNU
parse_datetime: Invalid input string: cannot be parsed as a relative time

[yuankunzhang]

That is a limitation of the chrono crate, it only support for years in the range [0, 9999]. We are hitting a hard wall here.

cc @sylvestre @cakebaker .

[tertsdiepraam]

Elsewhere we talked about using jiff instead I think. We could bring that discussion back?

[yuankunzhang]

The year range offered by jiff is [-9999, 9999], so it doesn't help with the situation we are having here :).

[tertsdiepraam]

Welp, that's unfortunate. Is this once again a case where we have to do our own thing then?

[yuankunzhang]

One possible solution is to rely on libc's localtime() function and the tm struct, but that seems to just cancel out the effort of "re-implementing in Rust".

[tertsdiepraam]

Sounds like a good idea. We have to use libc in a bunch of places anyway (and Rust code always uses libc). Or reimplement it indeed haha

[abhishekpradhan]

Hi all, I picked this up from the downstream date bug report (uutils/coreutils#9774) and implemented a Rust-side path for GNU-compatible large years (instead of relying on libc).

I initially opened one larger PR, and @sylvestre requested that it be split into smaller reviewable pieces. I’ve now done that:

1. Groundwork only (upstream): Groundwork: widen year parsing bounds for GNU max year #261
2. Extended runtime/API (ParsedDateTime + ExtendedDateTime): Add extended runtime + ParsedDateTime API for large years abhishekpradhan/parse_datetime#1
3. Parity tests + docs: Add large-year parity tests and README updates abhishekpradhan/parse_datetime#2

I don’t have upstream write access to create intermediate base branches, so PR2/PR3 are temporarily stacked in my fork. After PR1 merges, I’ll open equivalent upstream PRs sequentially against uutils/parse_datetime.

[abhishekpradhan]

Quick status update on large-year support (date parity work):

• Groundwork is merged in main: #261
• Runtime/API changes are now in active review: #263
• Tests/docs follow-up is prepared as a clean next PR branch and will be opened upstream right after Add extended runtime + ParsedDateTime API for large years #263 merges.

This split follows the review feedback to keep the changes incremental and easier to review.

[abhishekpradhan]

The PR that adds large-year parsing/runtime support, #263, has now been merged, so this should be fixed on main.

There is still a small follow-up cleanup in #272, and the coreutils work is currently pinned to the git commit from main. A 0.15.0 release will still be needed so that can switch back from the git dependency.