date: military format no longer offsets the current day by one

[Darius-Constantin]

Fixes #9775

Considering there was always an offset of 1 day ahead, I corrected it by subtracting a day. In case the subtraction fails (I am not sure if there is any real case when this happens), I fall back to the first date available (1970-01-01).

I am quite unsure of how a test could be written for this issue.

[github-actions]

GNU testsuite comparison:

Congrats! The gnu test tests/tail/inotify-dir-recreate is now passing!

[codspeed-hq]

CodSpeed Performance Report

Merging #9784 will not alter performance

_{Comparing Darius-Constantin:date-military-correct-day (fb4bbd4) with main (2d718f2)}

Summary

✅ 127 untouched
⏩ 6 skipped¹

Footnotes

1. 6 benchmarks were skipped, so the baseline results were used instead. If they were deleted from the codebase, click here and archive them to remove them from the performance reports. ↩

[cerdelen]

Hi! I also worked on this issue and wanted to point out a few edge cases that may not be fully covered by this implementation.

Military time doesn’t always require rolling the date back by one day. For example:

TZ=UTC-5 date -d "b5"

In this case, the date should remain the same day.

TZ=UTC-5 date -d "n23"

Here, the result should actually roll over to tomorrow.

PR #9785 addresses these cases and includes tests covering the full set of known edge cases. It might be worth comparing the approaches to ensure all scenarios are handled correctly.

[sylvestre]

also, it needs a test! please reopen when ready