date: date.pl gnu test tracker

[ChrisDryden]

Yesterday investigated all of the remaining failures in the main date.pl test to identify the root causes and see what it would take to fix the issues. Was able to come up with a prototype of changes that make all of the tests pass but came across some instances where the issues are upstream in the jiff library. Around half of those issues appear to be bugs, but the other half appear to be deliberate decisions.

Was hoping to start the discussions early on what those incompatibilities are to see if there's a possibility we could work with @BurntSushi to see if there is some sort of way that we can add specific features to Jiff under some sort of gating or flag.

To start off with the issues that can be resolved by directly changing the uutils code from:

5, dbg_5, 8, dbg_8, tz-5wf

These two tests are failing first because the default strtime::format uses %-I instead of %I which causes hours like 8 to be formatted as 8 instead of 08. This can be fixed by using a Jiff config to do the format and running it with PosixCustom::new() which uses the posix compliant default formats. The second issue here is that Jiff has taken the stance that when inproperly formatted formats are provided, instead of treating it as a literal it will return an error. Jiff has added the .lenient(true) flag to maintain compatibility so we just need to add that to the custom config.

// TODO: Switch to lenient formatting.
Ok(date) => match strtime::format(format_string, &date) {

let config = Config::new().custom(PosixCustom::new()).lenient(true)
match BrokenDownTime::from(&date).to_string_with_config(&config, format_string) {

relative-2

This is another one that can be addressed in uutils. Essentially we need read the -utc flag and modify the now that is passed to the formatter and set the timezone to UTC when this flag is set.

rel-2b, leap-1

The next issue is a bug in the parse_datetime library, which is not a big deal because its a uutils library. The high level gist is that the current behavior of the DateTimeBuilder where it was doing:

let days = dt.date().last_of_month().day() as i32;
Span::new().try_days(days.checked_mul(x))?

This converted months to days using the current month's length, which loses days when months have different lengths. This can just be fixed by changing the logic to not use the built in jiff function and make one that doesn't clamp based on the current month but actually determines the correct month. I did not find a different helper function that does that to swap to so we will probably have to add this new helper function in parse_datetime.

invalid-high-bit-set

This one is just non utf-8 handling, we just need to change the input to OsString, but this can be handled in the uutils implementation.

neg-secs, neg-secs2

These ones I think are actual bugs in the Jiff library that are not intended behaviors. When adding padding, the negative sign goes ontop of the padding and will produce outputs like - 22, instead of -22

Upstream Non-Bugs

subfmt-up1, date-century-plus

These two tests correspond to the modifiers %^c and %+. In the Jiff docs the %+ is explicitly stated as something that is not supported in Jiff because "* The %+ conversion specifier is not supported since there doesn't seem to be any consistent definition for it." Then there is also the ^ for c where in general the ^ modifier is supported, which is unclear whether that is a deliberate choice or whether it is something that is just incomplete.

What I was hoping to propose is that if @BurntSushi would be okay with it, is if we could do something similar to the lenient flag or a feature flag for GNU compatibility, to add the %+ conversion only as an opt in with the conditions that the + is following the GNU spec for it.

[BurntSushi]

These two tests are failing first because the default strtime::format uses %-I instead of %I which causes hours like 8 to be formatted as 8 instead of 08.

I think you're referring to %r here using %-I? I got confused as to what the "default strtime::format" means. The default %c is %Y M%m %-d, %a %H:%M:%S, so you're definitely going to want to provide your own thing (or use PosixCustom if that's good enough for you) here regardless of how %I is used.

The second issue here is that Jiff has taken the stance that when inproperly formatted formats are provided, instead of treating it as a literal it will return an error. Jiff has added the .lenient(true) flag to maintain compatibility so we just need to add that to the custom config.

Yes, this was specifically added for compatibility reasons: BurntSushi/jiff#428

Beware of the API stability of using this option, which is carefully documented here: https://docs.rs/jiff/latest/jiff/fmt/strtime/struct.Config.html#method.lenient

This converted months to days using the current month's length, which loses days when months have different lengths. This can just be fixed by changing the logic to not use the built in jiff function and make one that doesn't clamp based on the current month but actually determines the correct month. I did not find a different helper function that does that to swap to so we will probably have to add this new helper function in parse_datetime.

I don't think I understand this one. Can you say more? What about Span::new().try_months(x)?

These ones I think are actual bugs in the Jiff library that are not intended behaviors. When adding padding, the negative sign goes ontop of the padding and will produce outputs like - 22, instead of -22

Nice catch. I agree that this is a bug. I filed BurntSushi/jiff#485

Then there is also the ^ for c where in general the ^ modifier is supported, which is unclear whether that is a deliberate choice or whether it is something that is just incomplete.

I filed BurntSushi/jiff#486 for this. I think it's just a bug in Jiff. Note though that GNU date doesn't seem to respect %#c but does respect %^c. I'm not inclined to do one and not the other.

What I was hoping to propose is that if @BurntSushi would be okay with it, is if we could do something similar to the lenient flag or a feature flag for GNU compatibility, to add the %+ conversion only as an opt in with the conditions that the + is following the GNU spec for it.

This isn't really the sort of thing that feature flags should be used for. If it had to be opt-in thing, then it should be something in the API that exposes it.

With that said, what does %+ even do? It does nothing for me:

$ date +'%+'
%+

Note also that Jiff doesn't support the E or O modifiers. I'm not sure that it will.

I overall wouldn't be surprised if y'all had to roll your own strftime, perhaps by just copying what Jiff has, removing what you don't need and tweaking what you do need. Jiff can still do all of the "heavy lifting" in terms of datetime handling. I suggest this because it is a critical interface for your date application and it makes sense for y'all to be masters of your own destiny.

To be clear, I am willing to work with y'all and do reasonable things to attain some level of compatibility, but there are probably lines I won't cross (like promising bug-for-bug compatibility).

[collinfunk]

I haven't used jiff, so @BurntSushi please correct me if I am wrong. But I assume there is no desire for jiff to handle some of the complexities of GNU date.

GNU date can print dates that do not fit into the systems memory:

$ env time --format=%M date +%$(($(numfmt --from=iec 32G) - 1)) | wc -c | numfmt --to=iec
2124
32G

I assume the following limitation is from jiff:

$ ./target/debug/date +%$(($(numfmt --from=iec 32G) - 1))
date: invalid format '%34359738367' (strftime formatting failed: parsed width is too big, max is 255)

[ChrisDryden]

Thanks so much for the quick and in depth response, I should have split this in two to separate the jiff topics with the uutils topics,

%r here using %-I?

Yes, that was what I meant to say. It appears that the PosixCustom config passes all of the testing and fuzzing and I implemented the PR here to use it along with the lenient formatting: #10245

I don't think I understand this one. Can you say more? What about Span::new().try_months(x)?

I definitely explained this part poorly, the issue was on our end in here: uutils/parse_datetime#254 Essentially we were making integration tests that expected that when GNU adds months it uses the overflow method the dates is over the next month whereas jiff clamps to keep it in the same month. By doing that change I linked it fixes it. The examples are:

$ date -d "2024-01-31 1 month"
2024-03-02

$date -d "2024-03-31 1 month ago"
2024-03-02

With that said, what does %+ even do? It does nothing for me:

I was just doing some cursory investigation into this, it appears that the original source of this flag was from the POSIX.1-2008 / SUSv4 "to force the leading sign required by ISO 8601 expanded representations". The spec is outlined here: https://manpages.ubuntu.com/manpages/questing/man3/strftime.3posix.html

The tough part is that glibc never implemented this and still has it in the backlog, and I see that BSD uses + to represent something completely different.

[ChrisDryden]

@collinfunk, do you happen to have any other examples similar to that? I came across that limitation in my testing but I didn't mention it here since that I couldn't think of a use case for having > 256 paddings in a date. I could fix the issue by just patching to use a larger int instead of u8, but from a prioritization perspective I'd imagine implementing that patch would be one of the last GNU compatibility things that uutils would work on relative to the higher priority stuff. Definitely would understand not having this upstream in Jiff and I think its a relatively simple patch to maintain on the uutils side.

[BurntSushi]

I haven't used jiff, so @BurntSushi please correct me if I am wrong. But I assume there is no desire for jiff to handle some of the complexities of GNU date.

GNU date can print dates that do not fit into the systems memory:

$ env time --format=%M date +%$(($(numfmt --from=iec 32G) - 1)) | wc -c | numfmt --to=iec
2124
32G

I assume the following limitation is from jiff:

$ ./target/debug/date +%$(($(numfmt --from=iec 32G) - 1))
date: invalid format '%34359738367' (strftime formatting failed: parsed width is too big, max is 255)

Yes, that's from Jiff. Callers can use Jiff to format directly into, e.g., stdout, so the API foundations are there to support something like this. But no, the implementation is not really setup to handle pathological cases like this and I doubt the implementation complexity is worth it.

[ChrisDryden]

If you combine the open PR's linked here in uutils and the issues that were just made in Jiff, there's only two missing gnu integ test cases that are missing the >u8 support and %+ support. I was able to make a patch for jiff locally that adds the functionality for %+ and >u8 support to pass all of the date.pl GNU tests.

A question I have for the uutils maintainers when it comes to this, could we use a patch approach for the near term to achieve the 100% GNU compatibility then later once the more important compatibility issues are sorted out we can figure out a longer term approach to reduce the tech debt?

[BurntSushi]

@ChrisDryden I'd encourage you to submit PRs to Jiff with those patches. It's possible I'll take them with some changes.

[collinfunk]

@collinfunk, do you happen to have any other examples similar to that? I came across that limitation in my testing but I didn't mention it here since that I couldn't think of a use case for having > 256 paddings in a date. I could fix the issue by just patching to use a larger int instead of u8, but from a prioritization perspective I'd imagine implementing that patch would be one of the last GNU compatibility things that uutils would work on relative to the higher priority stuff. Definitely would understand not having this upstream in Jiff and I think its a relatively simple patch to maintain on the uutils side.

The only other one off the top of my head is the lack of the E modifier. It is used by some glibc locales, so it is quite important.

Speaking of which the most recent commit gives worse behavior in that case:

$ git show -s --pretty=reference 
f7b5f8f10 (CICD.yml: Upload uudoc at least for Linux-x64-glibc (#10231), 2026-01-15)
$ ./target/debug/date +"$(LC_ALL=th_TH.UTF-8 locale date_fmt)"
date: invalid format '%a %e %b %Ey %H:%M:%S %Z' (strftime formatting failed: found unrecognized specifier directive `E`)
$ { git checkout main; make; } > /dev/null 2>&1
$ git show -s --pretty=reference
450e7cfee (date: use PosixCustom formatting for GNU-compatible output (#10245), 2026-01-14)
$ ./target/debug/date +"$(LC_ALL=th_TH.UTF-8 locale date_fmt)"
Wed 14 Jan %Ey 16:47:21 PST