fix(date): read weekday names in -d instead of returning now

[xmakro]

What changed

date -d reads weekday names: monday, this fri, next tuesday, last sunday (full names or three-letter abbreviations, any case). They resolve the way GNU resolves them, at midnight in the sandbox TZ: a bare or this day may be today, next skips today, and last is the latest one before today. today is accepted as now. touch -d and find -newermt share the parser.

Any other unknown word after next/last (next blursday) is now invalid date with exit 1.

Why

next monday read monday as an unknown unit with a zero offset and printed the current time with exit 0, so scripts got a wrong date and no error.

Before / After

$ date -d 'next monday' '+%a %F %T'        # run on Friday 2026-10-09
Before: Fri 2026-10-09 05:58:34            (the current time)
After:  Mon 2026-10-12 00:00:00

$ date -d 'next blursday'; echo $?
Before: Fri Oct  9 05:58:34 UTC 2026, exit 0
After:  date: invalid date 'next blursday', exit 1

Both After lines match GNU date 9.12. Compared with GNU on 20 weekday and relative inputs in UTC, America/Los_Angeles and Australia/Sydney: all identical except next mins, which GNU reads as one minute and this reports as an invalid date (it used to print the current time).

Risk

• Low
• A script that relied on next <unknown word> returning the current time now gets an error, as with GNU.

Checklist

• Tests added or updated: unit tests and spec cases in date.test.sh
• Backward compatibility considered

Validation

• Reproduced the weekday/unknown-unit failures on current main before applying the contribution.
• Fixed a review finding: extreme virtual-clock timestamps could panic during local weekday conversion. The conversion now checks the timezone offset and returns an out-of-range error; regression covers both chrono extrema.
• Added shared date/touch/find coverage, strict newer-than comparisons, sandbox-calendar day boundaries, midnight DST gaps, and the no-tzdata build.
• 66 date unit tests, 19 timezone/shared-parser tests (including 42 GNU-date input/zone comparisons), and 9 no-tzdata tests passed.
• 158 repository-script tests, capability parity, OKF, source doc links, workflow/toolchain parity, changelog checks, and cargo vet passed.
• Local just pre-pr: formatting and workspace Clippy passed; 3,736 library tests passed. The integration binary aborts on macOS in blackbox_security_tests::finding_nested_cmd_subst_stack_overflow::depth_50_is_bounded. The exact test also aborts on clean latest main bd60cdc09e19e7bdc6e7ffd8247b5663fa7bb9fc; this is an existing baseline failure, not evidence against this date change.
• Final-head all-target/all-feature Clippy passed with warnings denied. Bash spec harness: 3,954 passed, 0 failed, 28 intentional skips.
• CLI smoke proof (2026-10-10), with a shared sandbox timezone:

  export TZ=America/Chicago
  date -d 'next monday' '+%a %F %T %z %s'
  Mon 2026-10-12 00:00:00 -0500 1791781200
  touch -d 'next monday' /tmp/stamp; date -r /tmp/stamp '+%a %F %T %z %s'
  Mon 2026-10-12 00:00:00 -0500 1791781200
  find /tmp/stamp -newermt 'next monday - 1 second'
  /tmp/stamp
  find /tmp/stamp -newermt 'next monday'
  [no output: equal timestamps do not match]
  date -d 'next blursday'; echo rejected=$?
  date: invalid date 'next blursday'
  rejected=1
  

• Both benchmark harnesses completed: Criterion parallel execution (including 1,000 shared-filesystem sessions; short 0.1s warmup/0.5s target measurements) and just bench (100% output agreement against Bash). Benchmark data is validation evidence, not a performance-regression claim.
• All 42 GitHub checks passed against final head 6541f04af4d2b898bba666be004205518d91ae72. CI run.

Security

No new dependencies, host filesystem reads, network access, unsafe code, or permissions. Weekdays use the existing sandbox-only timezone and virtual clock. Unknown relative units fail before touch creates a file; calendar arithmetic and timezone conversion are checked. Required knowledge and public compatibility documentation updated.

[chaliy]

Reviewed final commit 6541f04 against latest main bd60cdc. Approved for shipment; no blocking security, correctness, or project-alignment findings remain.

The contribution reuses the shared date parser and sandbox timezone/virtual-clock policy. Unknown relative units now fail instead of silently returning the current time. A review regression exposed a panic when timezone conversion pushed an extreme virtual timestamp outside chrono's range; fixed with checked conversion, covered at both extrema. Shared-caller, local-calendar, DST-midnight, invalid-input/file-effect, and no-tzdata coverage added. Knowledge and public compatibility docs updated; intentional unsupported forms recorded.

Validation: 66 date unit tests; 19 timezone/shared-parser tests including 42 executed GNU-date input/zone comparisons; 9 no-tzdata tests; 3,954 passing Bash spec cases with 28 intentional skips; real CLI smoke; 158 repository-script tests; all-target/all-feature Clippy with warnings denied; knowledge/doc/workflow/capability/changelog gates and cargo vet. Criterion parallel benchmark and just bench completed, with 100% output agreement in the Bash comparison. All final-head GitHub checks passed.

Local full just pre-pr is not green: it passes formatting, Clippy and all 3,736 library tests, then aborts on macOS in blackbox_security_tests::finding_nested_cmd_subst_stack_overflow::depth_50_is_bounded. The same exact test aborts on clean latest main, independently reproduced. This pre-existing platform baseline failure is disclosed in the PR validation notes.