From 9ce60b1958f1b285886bcfbb743f6419feacfc92 Mon Sep 17 00:00:00 2001 From: Serhii A Date: Thu, 3 Sep 2026 12:02:49 +0200 Subject: [PATCH] 1.4.3 release (#1376) MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit * 1.4.3 release notes Co-Authored-By: Claude Opus 5 (1M context) * Bump version: 1.4.2 → 1.4.3 --------- Co-authored-by: Claude Opus 5 (1M context) --- HISTORY.rst | 36 ++++++++++++++++++++++++++++++++++++ dateparser/__init__.py | 2 +- pyproject.toml | 2 +- 3 files changed, 38 insertions(+), 2 deletions(-) diff --git a/HISTORY.rst b/HISTORY.rst index de6c8b6d9..34de7131a 100644 --- a/HISTORY.rst +++ b/HISTORY.rst @@ -3,6 +3,42 @@ History ======= +1.4.3 (2026-09-03) +------------------ + +Fixes: + +- Make parsing thread-safe: parsing from several threads no longer + raises an intermittent ``KeyError`` from the shared language caches, + and a ``DATE_ORDER`` or ``RELATIVE_BASE`` value meant for one parse no + longer leaks into the settings that other parses read, where it could + make them return a wrong date (#1346) +- Do not share the language detector and the detected locale between + ``search_dates()`` calls, so concurrent searches over text in + different languages no longer return ``None`` or a date read in the + wrong locale (#1371) +- Resolve the ``BST`` and ``HDT`` timezone abbreviations to the offsets + the tz database gives them, UTC+1 (British Summer Time) and UTC-9 + (Hawaii-Aleutian Daylight Time), instead of +11 and -9:30, which no + zone goes by those names today; abbreviations that the tz database + maps to more than one offset, such as ``CST`` and ``IST``, keep their + current offset. Text carrying these abbreviations keeps its wall clock + but moves by 10 hours for ``BST`` and 30 minutes for ``HDT``, which can + put the parsed instant on a different day (#1366) +- Reject a ``%j`` (day of year) value that the parsed year does not + have, instead of rolling it over into the next year, so "1999366" with + ``date_formats=["%Y%j"]`` returns ``None`` rather than 2000-01-01. A + format with no year directive is checked against the year ``strptime`` + defaults to, 1900, which is not a leap year, so "366" with + ``date_formats=["%j"]`` now returns ``None`` where it used to return + January 1 (#1370) + +Cleanups and internal improvements: + +- Add CodSpeed benchmarks and a workflow that runs them, so a + performance regression such as the quadratic backtracking fixed in + 1.4.1 is reported on the pull request that introduces it (#1365) + 1.4.2 (2026-08-04) ------------------ diff --git a/dateparser/__init__.py b/dateparser/__init__.py index b43021910..565965882 100644 --- a/dateparser/__init__.py +++ b/dateparser/__init__.py @@ -1,4 +1,4 @@ -__version__ = "1.4.2" +__version__ = "1.4.3" from .conf import apply_settings from .date import DateDataParser diff --git a/pyproject.toml b/pyproject.toml index 71e6a8d61..55418df00 100644 --- a/pyproject.toml +++ b/pyproject.toml @@ -6,7 +6,7 @@ requires = [ [project] name = "dateparser" -version = "1.4.2" +version = "1.4.3" description = "Date parsing library designed to parse dates from HTML pages" authors = [ { name = "Scrapinghub", email = "opensource@zyte.com" },