Skip to content

BST is utc+1 instead of +11 - #1321

Closed
Sphynx-HenryAY wants to merge 1 commit into
scrapinghub:masterfrom
Sphynx-HenryAY:patch-2
Closed

Sphynx-HenryAY wants to merge 1 commit into
scrapinghub:masterfrom
Sphynx-HenryAY:patch-2

Conversation

@Sphynx-HenryAY

Copy link
Copy Markdown

No description provided.

@AdrianAtZyte

Copy link
Copy Markdown
Member

Thatβ€˜s arguable.

@AdrianAtZyte

Copy link
Copy Markdown
Member

But it also sounds like the most reasonable interpretation. The 11 value seems to be based in an old Alaska timezone, and the British one is the in the tz database.

@codecov

codecov Bot commented Apr 1, 2026 •

Copy link
Copy Markdown

Codecov Report

βœ… All modified and coverable lines are covered by tests.
βœ… Project coverage is 97.21%. Comparing base (3b4a816) to head (83e833a).

Additional details and impacted files
@@           Coverage Diff           @@
##           master    #1321   +/-   ##
=======================================
  Coverage   97.21%   97.21%           
=======================================
  Files         235      235           
  Lines        2905     2905           
=======================================
  Hits         2824     2824           
  Misses         81       81           

β˜” View full report in Codecov by Sentry.
πŸ“’ Have feedback on the report? Share it here.

πŸš€ New features to boost your workflow:
  • ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

serhii73 added a commit that referenced this pull request Aug 12, 2026
dateparser/timezones.py maps each timezone abbreviation to a single UTC
offset. Unrelated zones often share the same letters, and because the
table was scraped from Wikipedia, a few abbreviations ended up with a
meaning no tz database zone has. "BST" resolved to +11, although the
only zones named "BST" today are the UK ones, at +1 (#1321).

Rather than patching that one value, compare the whole table against the
tz database and fix every abbreviation it disagrees with:

- BST: 39600 -> 3600 (British Summer Time)
- HDT: -34200 -> -32400 (Hawaii-Aleutian Daylight Time, America/Adak)

Abbreviations the tz database names with several offsets, such as CST,
IST and PST, are left alone, because there is no single offset to
prefer. Abbreviations no zone is named after any more, such as AHST and
LMT, are kept so historical text still parses.

The comparison lives in dateparser_scripts/tz_abbreviation_conflicts.py
and uses pytz, already a dependency, whose bundled copy of the tz
database gives the same answer on every platform; zoneinfo would depend
on OS-provided data that Windows lacks without the tzdata package.
Parsing is unchanged and still uses the static table.

Fixes #1322

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
serhii73 added a commit that referenced this pull request Aug 12, 2026
dateparser/timezones.py maps each timezone abbreviation to a single UTC
offset. Unrelated zones often share the same letters, and because the
table was scraped from Wikipedia, a few abbreviations ended up with a
meaning no tz database zone has. "BST" resolved to +11, although the
only zones named "BST" today are the UK ones, at +1 (#1321).

Rather than patching that one value, compare the whole table against the
tz database and fix every abbreviation it disagrees with:

- BST: 39600 -> 3600 (British Summer Time)
- HDT: -34200 -> -32400 (Hawaii-Aleutian Daylight Time, America/Adak)

Abbreviations the tz database names with several offsets, such as CST,
IST and PST, are left alone, because there is no single offset to
prefer. Abbreviations no zone is named after any more, such as AHST and
LMT, are kept so historical text still parses.

The comparison lives in dateparser_scripts/tz_abbreviation_conflicts.py
and uses pytz, already a dependency, whose bundled copy of the tz
database gives the same answer on every platform; zoneinfo would depend
on OS-provided data that Windows lacks without the tzdata package.
Parsing is unchanged and still uses the static table.

Fixes #1322

Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com>
@AdrianAtZyte

Copy link
Copy Markdown
Member

Fixed in #1366, released in dateparser 1.4.3 (2026-09-03).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants