Rust-DateParser v1.4.7

Dependency-only refresh to published Dateutil v2.9.1. DateParser runtime algorithms, public APIs, locale/conversion data, and caller-owned concurrency are unchanged.

Dependency: Rust-Dateutil v2.9.1 at 3a7537dd3a4e223756fa31fb1941a10da4c78b30.
Source commit: 1e3e2feccd8662113e4092ca87a5567e4e23bc3c.

Python dateparser 1.4.3 and python-dateutil 2.9.0.post0 remain the behavioral references. CPython 3.14.6 rechecked the current Go dependency graph: the same 75 core and 16 search-result corrections passed. Historical fixtures and their original source identities are unchanged.

Local qualification: Rust 1.98.1 Linux debug/release and Windows GNU release tests: 52 tests plus 3 doctests; strict Clippy and formatting; both live Go checks; clean committed source-archive tests with locked offline dependencies.

Existing v1.4.3/v1.4.5/v1.4.6 benchmark measurements retain their original version labels. No v1.4.7 performance measurement or gain is claimed.

See the versioned README for installation, historical measurements, reproduction commands and compatibility limits.

GitHub source release only, not crates.io. Cargo Git builds are verified. Registry packaging requires publication of the Git-only rust-dateutil dependency and is not supported.

v1.4.6: Python-compatible Dateutil integration

Changes

• Integrate published Rust-Dateutil v2.9.0, pinned to commit 205702d70c3b9190cb2b3474cf1593f913549a61; no Go or Python runtime is required.
• Follow Python relativedelta month-end clamping and fractional-second precision; reject fractional years/months instead of approximating them.
• Reject explicitly invalid Gregorian dates while preserving omitted-field clamping and valid omitted-year leap-date selection.
• Keep preserve_end_of_month as a compatibility field with no effect, and retain Go-specific period labels separately from arithmetic.
• Preserve the original Go v1.4.5 fixtures and all inputs. A separate Python-verified correction fixture records 75 core and 16 search-result updates from the corrected Go source.
• Keep caller-owned concurrency, native Rust execution, existing locale/calendar data and license notices.

Performance

These two comparisons share one pre-release three-engine measurement on
2026-09-13: published Rust v1.4.5, Rust v1.4.6, and Go v1.4.6
at its review commit 7837629. The Rust baseline is the untouched
published source at 0dc203dc0a68968d925a3b9d5cffcba2e73f5c62, before Dateutil
integration. The 1.4.6 releases retain the measured runtimes unchanged; the raw
report preserves the original pre-release source and executable identities.

All engines use portable optimized builds on an AMD Ryzen AI 7 PRO 350,
Linux x86_64/WSL2, with Rust 1.98.1 and Go 1.27.1. Execution is pinned to CPU 2
with one parsing caller and no internal parallelism. Go uses GOMAXPROCS=1,
CGO_ENABLED=0, GOAMD64=v1, default garbage collection and its pure-Go backend.

Rust v1.4.5 To v1.4.6

Times are milliseconds per complete corpus traversal. An Old/New ratio above
1 means Rust v1.4.6 took less time.

Cohort	Inputs (Parsed)	Rust v1.4.5	Rust v1.4.6	Old/New Time
Automatic locale detection	226 (222)	15.66 ms	14.99 ms	1.04x
Explicit locales/languages	2,530 (2,388)	43.41 ms	41.15 ms	1.05x
HtmlDate strict/past	195 (167)	25.59 ms	25.32 ms	1.01x
Automatic search	3 (3)	1.14 ms	1.09 ms	1.05x
Split search	34 (29)	0.90 ms	0.87 ms	1.03x
N-gram search	39 (36)	3.32 ms	3.49 ms	0.95x
Time-span search	96 (96)	2.20 ms	2.35 ms	0.94x
Jalali parsing	1,311 (1,087)	7.29 ms	7.67 ms	0.95x
Hijri parsing	6,193 (5,994)	8.27 ms	8.49 ms	0.97x

The before/after per-process timing ranges overlap in all nine rows. Small
differences do not establish a performance regression or gain amid run variation.
Earlier repeats were variable, including automatic-locale candidate process
medians from 16.74 to 56.38 ms; those samples are retained in the raw report.
The runs do not establish a consistent Dateutil-related slowdown or prove
performance equivalence on other workloads.

Rust And Go v1.4.6

The Rust column is the same pre-release measurement as above; a Go/Rust ratio
above 1 means Rust took less time.

Cohort	Inputs (Parsed)	Rust v1.4.6	Go v1.4.6	Go/Rust Time
Automatic locale detection	226 (222)	14.99 ms	175.03 ms	11.67x
Explicit locales/languages	2,530 (2,388)	41.15 ms	836.73 ms	20.33x
HtmlDate strict/past	195 (167)	25.32 ms	255.27 ms	10.08x
Automatic search	3 (3)	1.09 ms	10.10 ms	9.31x
Split search	34 (29)	0.87 ms	24.24 ms	27.76x
N-gram search	39 (36)	3.49 ms	68.65 ms	19.69x
Time-span search	96 (96)	2.35 ms	22.48 ms	9.56x
Jalali parsing	1,311 (1,087)	7.67 ms	13.26 ms	1.73x
Hijri parsing	6,193 (5,994)	8.49 ms	48.85 ms	5.75x

Go reaches the first validated full pass sooner for automatic detection and
the HtmlDate configuration. Warmed parsing results do not imply startup gains.
"HtmlDate strict/past" measures DateParser with custom-format and absolute
parsers only; it does not run an HtmlDate library or HTML extraction.

Method And Reproduction

All three engines receive the same inputs. The three core cohorts contain
2,951 stateless public cases from the core fixture, with
their original settings, formats and frozen reference times; the existing
16 detector/history cases are excluded. Each version validates its exact
expected outputs, including rejections, before timing. The candidates apply the
separate Python-verified corrections; the published baseline keeps its original
expected outputs. No inputs were changed to accommodate the integration.
The six feature cohorts contain 7,676 Python-reference cases, excluding the
existing six callbacks and ten Python exception inputs. All feature output
checks pass. Parsed counts count inputs yielding at least one date, not individual
matches or accuracy.

Each table value is the median of six per-process pass medians. Each process
performs eight measured passes after a validated first pass. Feature passes
repeat the corpus 16 times and are divided by 16 here. All six engine-order
permutations are used once per cohort; separate preflights are discarded, but no
measured samples are dropped. Setup, fixture decoding, initial matcher/regex
construction and output checks are outside the warm timers. Automatic search has
only three texts. Compare engines within a row, not different cohorts. These
regression-corpus measurements are not a production throughput guarantee.

The raw report retains all 162 processes and
1,296 warm passes from this shared comparison, per-process ranges, first-pass
latency, execution orders, binary/source hashes and module provenance. Earlier
two-engine runs are retained separately, without pooling or relabelling them.
This is a dated measurement of the identified candidates, not every later build.

Reproduce from the repository root under Linux/WSL with Python 3.9+, Rust 1.98.1
and Go 1.27.1. First build an untouched archive of the published Rust baseline:

mkdir -p target/benchmark/baseline-v1.4.5
git archive 0dc203dc0a68968d925a3b9d5cffcba2e73f5c62 |
  tar -x -C target/benchmark/baseline-v1.4.5
RUSTFLAGS= CARGO_ENCODED_RUSTFLAGS= CARGO_BUILD_JOBS=1 \
  cargo test --locked --release --lib --no-run \
  --manifest-path target/benchmark/baseline-v1.4.5/Cargo.toml \
  --target-dir target/benchmark/baseline-v1.4.5/target
baseline=$(find target/benchmark/baseline-v1.4.5/target/release/deps \
  -maxdepth 1 -type f -executable -name 'rust_dateparser-*')

Use a Go checkout at commit 7837629bf3773c8d94524ec603706bec9a0c665b:

python3 tools/benchmark.py --rust-baseline "$baseline" \
  --go-source /path/to/go-dateparser \
  --engine rust-baseline --engine rust --engine go-worktree \
  --runs 6 --passes 8 --cpu 2 --output target/benchmark/review-core.json
python3 tools/benchmark.py --rust-baseline "$baseline" \
  --go-source /path/to/go-dateparser \
  --engine rust-baseline --engine rust --engine go-worktree \
  --features --runs 6 --passes 8 --iterations 16 --cpu 2 \
  --output target/benchmark/review-features.json

tools/benchmark.py builds the current runners and enforces
single-core execution. The benchmark-only Go replacement lives in a temporary
module; library lockfiles and the published v1.4.5 fixture exporter are unchanged.
Select another available CPU with --cpu when necessary. New raw samples go
under the ignored target/benchmark/ directory, without replacing the checked-in
review report.

Verification

The reviewed runtime passed Linux and Windows/MSVC CI, plus local Windows/GNU qualification: 52 tests and three README examples. Formatting, strict Clippy, release builds and byte-identical Python correction regeneration passed. The release-preparation commit changes documentation only. This is a GitHub source release, not a crates.io publication.

RustDateParser v1.4.5

RustDateParser v1.4.5 mirrors Go-DateParser v1.4.5 and Python dateparser v1.4.3.

Rust release numbering follows the Go reference. Python dateparser v1.4.3 remains the behavioral authority; this is not a reference to Python dateparser v1.4.5.

Included

• Localized absolute and relative date parsing, Unix timestamps, and explicit Go-layout formats.
• Split and n-gram search, full-text language detection, and time spans.
• Native Jalali and Hijri/Umm al-Qura calendar parsing with Python-verified conversion tables and boundary handling.
• Search, calendar, and overflow fidelity corrections aligned with Go v1.4.5.
• Single-threaded optimizations. The library starts no worker threads; callers own concurrency.

Verification

• The versioned suite passes 50 default tests and three doctests, with no filtered default tests.
• Exact Go fixture comparisons cover 4,302 core parsing cases, 8,952 language cases, and 9,886 supplementary search/calendar cases, without substituted inputs or excluded Go cases.
• Independent Python v1.4.3 fixtures cover 7,504 calendar cases, 178 exact search cases, and ten exception-safety inputs.
• Formatting, strict Clippy, and the optimized release build pass.

Requires Rust 1.98.1. No Go, Python, native RE2 library, or network service is required at runtime.

Mirroring identifies the upstream reference versions, not an exhaustive compatibility guarantee for every input. See the tagged coverage and compatibility limits, verification instructions, and dated performance comparison.