v1.4.8

Locale data is now built on first use instead of in package init (#25, thanks @macintacos). Parsing results, public APIs, locale/conversion data, caller-owned concurrency, the Go 1.26 minimum and the Go-Dateutil v2.9.1 dependency are unchanged.

• Importing the package no longer compiles ~4,600 regexes for all 211 locale files: internal/data init drops from roughly 90 ms to over 1 s depending on hardware (99 MB, 389k allocations) to under 0.1 ms (47 KB, 418 allocations). Each language builds once, together with its regional variants, the first time it is requested; loading is goroutine-safe via sync.OnceFunc.
• With no Locales, Languages or Region configured, the first Parse or Search now pays the full locale build. Set Languages or Locales to build only what is needed; see Locale Loading. Warm parsing speed and per-call allocations are unchanged.
• The code generator emits per-file loaders and no longer deletes hand-written _test.go files when regenerating internal/data. New tests check that locales are not built at init, that sub-locales build with their parent, and that every locale builds.

Source commit: 17684bff85634c7598d70c027adaade64338df2f.

Python dateparser 1.4.3 and python-dateutil 2.9.0.post0 remain the behavioral references; existing Python-derived fixtures pass unchanged.

Local qualification: Windows Go 1.27.1 go vet ./... and go test ./...; internal/data tests with -count=3 -shuffle=on.

Existing v1.4.3/v1.4.5/v1.4.6 benchmark measurements retain their original version labels; they are warm-pass timings that exclude first-use initialization. No new warm-pass performance gain is claimed.

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