[AdrianAtZyte]

Resolves #683, fixes #580

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 99.03%. Comparing base (a3d3b89) to head (70dbda1).
⚠️ Report is 1 commits behind head on master.

Additional details and impacted files

@@           Coverage Diff           @@
##           master    #1415   +/-   ##
=======================================
  Coverage   99.03%   99.03%           
=======================================
  Files         239      239           
  Lines        3838     3850   +12     
=======================================
+ Hits         3801     3813   +12     
  Misses         37       37           

☔ View full report in Codecov by Harness.
📢 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.

[codspeed]

Merging this PR will not alter performance

✅ 10 untouched benchmarks

---

_{Comparing AdrianAtZyte:timezone-abbreviations (70dbda1) with master (a3d3b89)}

[serhii73]

Code review (claude code-review, at 795e974). The setting is opt-in, so default behaviour is unchanged and I found no regression. The points below come from reading the call sites, not from running them.

Non-blocking notes:

• Only the date_parser.py and freshness_date_parser.py call sites pass settings. The pop_tz_offset_from_string calls in date.py and languages/locale.py still use the built-in offsets, so with an override such as IST = +05:30 and input 10:00 +05:30 IST, the parser strips both tokens but the is_applicable check may not, which could leave a stray IST and make parse() return None. A test of the redundant-offset dedup with an override would settle this.
• The override is not used for TIMEZONE / TO_TIMEZONE (get_timezone_from_tz_string and apply_dateparser_timezone read the table directly), so TO_TIMEZONE='IST' would still convert with the default offset. Either apply it there or document that it is not.
• Validation accepts only exact upper-case keys, although abbreviations match case-insensitively ({'ist': ...} is rejected). It requires a dict while the annotation says Mapping, and it does not check that keys are strings. For a name that appears more than once in the table (e.g. IST), only the first entry is overridden.
• The cache key is built from f'{key}-{settings[key]}', so equal dicts in a different order create separate cache entries, and mutating the dict after the first parse leaves the cached parser with the old offsets.
• offset_of is rebuilt as a closure on every call even when the setting is empty; resolving the overrides once would avoid that on the hot path.
• Docs should state which names are valid, that unknown ones raise SettingValidationError, that keys are case-sensitive, and whether TIMEZONE/search_dates are affected.