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 degrade performance by 4.4%

_{Comparing Darius-Constantin:date-military-correct-day (96e5538) with main (836e5d1)}

Summary

⚡ 1 improvement
❌ 1 regression
✅ 125 untouched
⏩ 6 skipped¹

⚠️ Please fix the performance issues or acknowledge them on CodSpeed.

Benchmarks breakdown

	Benchmark	BASE	HEAD	Efficiency
⚡	sort_ascii_c_locale	22.6 ms	21.5 ms	+4.73%
❌	mv_force_overwrite	138 ms	144.4 ms	-4.4%

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.