Repository navigation
fix(date): accept HH:MM date-times and zone suffixes in -d - #2662
Conversation
`date -d` (and `touch -d`, `find -newermt`, which share the parser) only took ISO dates with full seconds and no zone. It now also reads `YYYY-MM-DD HH:MM`, an optional fraction of a second, and a trailing `UTC`/`GMT`, `Z` or numeric offset (`+0200`, `+02:00`, `-05`), which covers git's `%ci` format.
chaliy
left a comment
There was a problem hiding this comment.
Approved reviewed revision e260f1e. No blocking security, correctness, or alignment findings.
The change extends the existing shared date parser, preserving sandbox-only timezone authority, authoritative explicit offsets, and validated chrono formats. No dependency, workflow, host-I/O, network, or unsafe-code changes are introduced relative to current main.
Added the required canonical knowledge update and regressions covering consistent instants across date/touch/find, fractional file timestamps, strict newer-than comparisons, and rejection before file effects. The positive regression fails on clean main and passes with the contribution.
Validation: all 42 CI checks passed on this exact head. Local date unit/timezone tests, GNU date 9.12 differentials, lean-build tests, 3,952 Bash spec cases, full workspace Clippy, 3,732 library tests, 158 repository-script tests, drift checks, and cargo vet passed.
Local full-gate limitation: just pre-pr aborts on macOS in blackbox_security_tests::finding_nested_cmd_subst_stack_overflow::depth_50_is_bounded. The same SIGABRT/stack overflow reproduces on clean main 28a7f02 with the same workspace feature configuration. This predates the contribution; the full local gate is not claimed green. Details and baseline command are recorded in the PR description.
What changed
date -dnow accepts ISO date-times without seconds and with a zone.touch -dandfind -newermtshare the parser and gain the same forms.YYYY-MM-DD HH:MM(withTor a space), and an optional fraction after the secondsUTC/GMT,Z, or a numeric offset (+0200,+02:00,-05), so git's%cioutput parsesThe change is a few more chrono formats next to the existing ones; chrono validates the fields and the offset range.
Why
Only
YYYY-MM-DDandYYYY-MM-DD HH:MM:SSwithout a zone were accepted, so common inputs such as a minute-precision timestamp, a UTC log line or a git commit date failed withinvalid date.Before / After
Every After line matches GNU date 9.12. Compared with GNU on 31 date-time inputs in UTC and America/Los_Angeles: the only differences are rare forms this still rejects (a comma fraction
14:30:15,5, an exact-2400offset,2026-10-08Z), and12:30:60, which bashkit already accepted before this change.Risk
Checklist
date.test.sh, three rows in the GNUdatedifferential testMaintainer validation
Synced with current main; added the required knowledge update and shared-parser integration regressions. The contributor's parsing implementation is unchanged.
date/touch/findregression fails on clean main and passes with this change.find -newermtcomparisons passed.cargo fmt --all -- --check,cargo clippy -p bashkit --lib --tests -- -D warnings, OKF and doc-link checks passed.Local full-gate limitation
Full workspace Clippy passed.
just pre-prpassed all 3,732 library tests, then aborted on macOS inblackbox_security_tests::finding_nested_cmd_subst_stack_overflow::depth_50_is_bounded(SIGABRT/stack overflow). The same focused test reproduces on clean current main28a7f0210896462e7a2ba8c7382ab08ee5a23975, with the same workspace feature configuration. This is a pre-existing project failure, not introduced by this date change; the full local gate is therefore not claimed green.Baseline command:
cargo test blackbox_security_tests::finding_nested_cmd_subst_stack_overflow::depth_50_is_bounded -- --exact --nocapture.Remaining local gates were run separately after the unrelated stack abort: 158 repository-script tests, capability/OKF/doc-link/workflow/changelog checks, and
cargo vet --lockedpassed.Final CI: all 42 checks passed on reviewed head
e260f1e40a7c84e392d9e12e7db7d88edcf1534a.