Add utils::list_long_breaks function to find consecutive holidays#3001
Add utils::list_long_breaks function to find consecutive holidays#3001arkid15r merged 26 commits intovacanza:devfrom
utils::list_long_breaks function to find consecutive holidays#3001Conversation
|
Caution Review failedFailed to post review comments Summary by CodeRabbit
✏️ Tip: You can customize this high-level summary in your review settings. WalkthroughAdds a new public utility function Changes
Estimated code review effort🎯 3 (Moderate) | ⏱️ ~25 minutes Suggested reviewers
Pre-merge checks and finishing touches❌ Failed checks (2 warnings, 2 inconclusive)
✅ Passed checks (1 passed)
✨ Finishing touches
🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
There was a problem hiding this comment.
Actionable comments posted: 3
📜 Review details
Configuration used: Path: .coderabbit.yaml
Review profile: ASSERTIVE
Plan: Pro
📒 Files selected for processing (2)
holidays/utils.py(2 hunks)tests/test_utils.py(2 hunks)
🧰 Additional context used
🧠 Learnings (4)
📚 Learning: 2025-04-05T06:49:06.217Z
Learnt from: PPsyrius
PR: vacanza/holidays#2386
File: tests/countries/test_nepal.py:499-536
Timestamp: 2025-04-05T06:49:06.217Z
Learning: In the holidays project, test files follow a dual testing approach: individual methods test specific holidays across multiple years, while comprehensive year-specific tests (e.g., `test_2025`) verify all holidays for a specific year in a single assertion. Both approaches serve different testing purposes and complement each other.
Applied to files:
tests/test_utils.py
📚 Learning: 2025-08-12T17:16:54.497Z
Learnt from: PPsyrius
PR: vacanza/holidays#2794
File: tests/calendars/test_julian.py:35-36
Timestamp: 2025-08-12T17:16:54.497Z
Learning: In the vacanza/holidays project calendar tests (Thai, Ethiopian, Julian, etc.), the established testing pattern for validation methods is to use simple for loops like `for year in known_data_dict:` followed by `self.assertEqual(expected, actual)` without using unittest's subTest feature. This pattern is consistently maintained across all calendar test files.
Applied to files:
tests/test_utils.py
📚 Learning: 2025-04-05T04:47:27.213Z
Learnt from: PPsyrius
PR: vacanza/holidays#2416
File: tests/countries/test_turkmenistan.py:52-64
Timestamp: 2025-04-05T04:47:27.213Z
Learning: For holiday tests in the vacanza/holidays project, structure tests by individual holidays rather than by years. Each test method should focus on a specific holiday and test it across multiple years (from start_year through 2050) using helper methods like `assertHolidayName`. For fixed holidays, use generators like `(f"{year}-01-01" for year in range(1991, 2051))`. For movable holidays, specify individual dates for specific years followed by a range check.
Applied to files:
tests/test_utils.py
📚 Learning: 2025-09-10T14:35:54.603Z
Learnt from: PPsyrius
PR: vacanza/holidays#2881
File: tests/countries/test_brazil.py:28-30
Timestamp: 2025-09-10T14:35:54.603Z
Learning: In the holidays project, the test_no_holidays method should test ALL supported_categories (via categories=CountryClass.supported_categories) rather than just the default PUBLIC category, to ensure comprehensive validation that no holidays exist before start_year across any supported category including OPTIONAL and subdivision categories.
Applied to files:
tests/test_utils.py
🧬 Code graph analysis (2)
holidays/utils.py (1)
holidays/holiday_base.py (1)
get_nth_working_day(1092-1116)
tests/test_utils.py (1)
holidays/utils.py (1)
list_long_weekends(442-487)
🪛 Ruff (0.13.3)
tests/test_utils.py
226-226: Use a regular assert instead of unittest-style assertEqual
Replace assertEqual(...) with assert ...
(PT009)
232-232: Use a regular assert instead of unittest-style assertIsInstance
Replace assertIsInstance(...) with assert ...
(PT009)
233-233: Use a regular assert instead of unittest-style assertTrue
Replace assertTrue(...) with assert ...
(PT009)
237-237: Use a regular assert instead of unittest-style assertEqual
Replace assertEqual(...) with assert ...
(PT009)
241-241: Use a regular assert instead of unittest-style assertIsInstance
Replace assertIsInstance(...) with assert ...
(PT009)
246-246: Use a regular assert instead of unittest-style assertIsInstance
Replace assertIsInstance(...) with assert ...
(PT009)
247-247: Use a regular assert instead of unittest-style assertIsInstance
Replace assertIsInstance(...) with assert ...
(PT009)
248-248: Use a regular assert instead of unittest-style assertIsInstance
Replace assertIsInstance(...) with assert ...
(PT009)
252-252: Use a regular assert instead of unittest-style assertIsInstance
Replace assertIsInstance(...) with assert ...
(PT009)
🔇 Additional comments (1)
holidays/utils.py (1)
21-22: Public API export looks goodAdding list_long_weekends to all aligns with existing naming (list_*).
Codecov Report✅ All modified and coverable lines are covered by tests. Additional details and impacted files@@ Coverage Diff @@
## dev #3001 +/- ##
=========================================
Coverage 100.00% 100.00%
=========================================
Files 306 306
Lines 18264 18288 +24
Branches 2330 2336 +6
=========================================
+ Hits 18264 18288 +24 ☔ View full report in Codecov by Sentry. 🚀 New features to boost your workflow:
|
There was a problem hiding this comment.
Actionable comments posted: 6
♻️ Duplicate comments (2)
tests/test_utils.py (2)
224-228: Remove duplicate parity assertion (already checked above).This repeats the parity check done at Lines 220-223. Trim to avoid double work.
- financial_files = [ - path for path in Path("holidays/financial").glob("*.py") if path.stem != "__init__" - ] - self.assertEqual(len(financial_files), len(supported_financial)) -
244-249: Add a cross‑year boundary test (New Year’s).Covers spans that start in prior year. Mirrors the feature’s doc intent.
class TestListLongWeekends(unittest.TestCase): @@ def test_no_holidays(self): instance = MockHolidayBase([]) result = list_long_weekends(instance) self.assertEqual(result, []) + + def test_cross_year_boundary(self): + # US 2024: New Year's Day on Monday yields Sat 2023‑12‑30 to Mon 2024‑01‑01. + us = holidays.country_holidays("US", years=2024) + result = list_long_weekends(us) + self.assertTrue(any(start.year == 2023 and end.year == 2024 for start, end in result))Based on learnings
Also applies to: 250-259, 260-271, 272-278
📜 Review details
Configuration used: Path: .coderabbit.yaml
Review profile: ASSERTIVE
Plan: Pro
📒 Files selected for processing (2)
holidays/utils.py(2 hunks)tests/test_utils.py(3 hunks)
🧰 Additional context used
🧠 Learnings (3)
📚 Learning: 2025-09-14T17:17:14.387Z
Learnt from: PPsyrius
PR: vacanza/holidays#2881
File: tests/countries/test_saint_helena_ascension_and_tristan_da_cunha.py:209-209
Timestamp: 2025-09-14T17:17:14.387Z
Learning: In tests/countries/test_saint_helena_ascension_and_tristan_da_cunha.py, the explicit loop iteration pattern for subdivision-specific holiday checks (like Anniversary Day for TA subdivision) is intentionally preferred over using assertSubdivTa helper methods, as confirmed by PPsyrius.
Applied to files:
tests/test_utils.py
📚 Learning: 2025-04-05T04:47:27.213Z
Learnt from: PPsyrius
PR: vacanza/holidays#2416
File: tests/countries/test_turkmenistan.py:52-64
Timestamp: 2025-04-05T04:47:27.213Z
Learning: For holiday tests in the vacanza/holidays project, structure tests by individual holidays rather than by years. Each test method should focus on a specific holiday and test it across multiple years (from start_year through 2050) using helper methods like `assertHolidayName`. For fixed holidays, use generators like `(f"{year}-01-01" for year in range(1991, 2051))`. For movable holidays, specify individual dates for specific years followed by a range check.
Applied to files:
tests/test_utils.py
📚 Learning: 2025-04-05T04:29:38.042Z
Learnt from: PPsyrius
PR: vacanza/holidays#2416
File: tests/countries/test_turkmenistan.py:85-86
Timestamp: 2025-04-05T04:29:38.042Z
Learning: For testing holiday implementations in the vacanza/holidays repository, recommend using `from tests.common import CommonCountryTests` as the base class instead of directly using `unittest.TestCase` to maintain consistency with project conventions and leverage common test utilities.
Applied to files:
tests/test_utils.py
🧬 Code graph analysis (2)
tests/test_utils.py (2)
holidays/holiday_base.py (1)
HolidayBase(57-1304)holidays/utils.py (1)
list_long_weekends(442-477)
holidays/utils.py (1)
holidays/holiday_base.py (1)
get_nth_working_day(1099-1123)
🪛 Ruff (0.14.0)
tests/test_utils.py
227-227: Use a regular assert instead of unittest-style assertEqual
Replace assertEqual(...) with assert ...
(PT009)
231-231: Missing return type annotation for special method __init__
Add return type annotation: None
(ANN204)
231-231: Do not use mutable data structures for argument defaults
Replace with None; initialize within function
(B006)
239-239: Missing return type annotation for special method __contains__
Add return type annotation: bool
(ANN204)
248-248: Use a regular assert instead of unittest-style assertEqual
Replace assertEqual(...) with assert ...
(PT009)
258-258: Use a regular assert instead of unittest-style assertEqual
Replace assertEqual(...) with assert ...
(PT009)
264-264: Use a regular assert instead of unittest-style assertEqual
Replace assertEqual(...) with assert ...
(PT009)
270-270: Use a regular assert instead of unittest-style assertEqual
Replace assertEqual(...) with assert ...
(PT009)
276-276: Use a regular assert instead of unittest-style assertTrue
Replace assertTrue(...) with assert ...
(PT009)
277-277: Use a regular assert instead of unittest-style assertTrue
Replace assertTrue(...) with assert ...
(PT009)
282-282: Use a regular assert instead of unittest-style assertEqual
Replace assertEqual(...) with assert ...
(PT009)
holidays/utils.py
444-444: Boolean-typed positional argument in function definition
(FBT001)
444-444: Boolean default positional argument in function definition
(FBT002)
🔇 Additional comments (2)
tests/test_utils.py (1)
279-282: LGTM: empty input returns empty list.holidays/utils.py (1)
21-21: Public API export looks good.
There was a problem hiding this comment.
Actionable comments posted: 1
♻️ Duplicate comments (2)
tests/test_utils.py (2)
224-228: Remove the duplicate parity assertion.This repeats the same check from lines 220-223. One assertion is enough.
- financial_files = [ - path for path in Path("holidays/financial").glob("*.py") if path.stem != "__init__" - ] - self.assertEqual(len(financial_files), len(supported_financial)) -
230-234: Fix the mutable default argument.The
weekend={5, 6}default is mutable (Ruff B006). Replace withNoneand initialize inside the method:- def __init__(self, holidays, weekend={5, 6}): + def __init__(self, holidays, weekend=None): super().__init__() self._holidays = set(holidays) - self.weekend = weekend + self.weekend = weekend if weekend is not None else {5, 6}Optionally, add type hints for clarity:
- def __init__(self, holidays, weekend=None): + def __init__(self, holidays, weekend=None) -> None:
📜 Review details
Configuration used: Path: .coderabbit.yaml
Review profile: ASSERTIVE
Plan: Pro
📒 Files selected for processing (2)
holidays/utils.py(2 hunks)tests/test_utils.py(3 hunks)
🧰 Additional context used
🧠 Learnings (4)
📚 Learning: 2025-09-14T17:17:14.387Z
Learnt from: PPsyrius
PR: vacanza/holidays#2881
File: tests/countries/test_saint_helena_ascension_and_tristan_da_cunha.py:209-209
Timestamp: 2025-09-14T17:17:14.387Z
Learning: In tests/countries/test_saint_helena_ascension_and_tristan_da_cunha.py, the explicit loop iteration pattern for subdivision-specific holiday checks (like Anniversary Day for TA subdivision) is intentionally preferred over using assertSubdivTa helper methods, as confirmed by PPsyrius.
Applied to files:
tests/test_utils.py
📚 Learning: 2025-04-05T04:47:27.213Z
Learnt from: PPsyrius
PR: vacanza/holidays#2416
File: tests/countries/test_turkmenistan.py:52-64
Timestamp: 2025-04-05T04:47:27.213Z
Learning: For holiday tests in the vacanza/holidays project, structure tests by individual holidays rather than by years. Each test method should focus on a specific holiday and test it across multiple years (from start_year through 2050) using helper methods like `assertHolidayName`. For fixed holidays, use generators like `(f"{year}-01-01" for year in range(1991, 2051))`. For movable holidays, specify individual dates for specific years followed by a range check.
Applied to files:
tests/test_utils.py
📚 Learning: 2025-03-23T16:59:25.794Z
Learnt from: PPsyrius
PR: vacanza/holidays#2362
File: tests/test_ical.py:31-40
Timestamp: 2025-03-23T16:59:25.794Z
Learning: In the holidays library's `TestIcalExporter` class, initializing `ICalExporter` with `None` is intentional. Using a mock object instead breaks tests because the constructor performs attribute validation with `getattr(self.holidays, "language", None)` which returns a mock with a mock object instead of `None`, causing validation failures. The approach isolates file operation tests from iCal generation logic.
Applied to files:
tests/test_utils.py
📚 Learning: 2025-04-05T04:29:38.042Z
Learnt from: PPsyrius
PR: vacanza/holidays#2416
File: tests/countries/test_turkmenistan.py:85-86
Timestamp: 2025-04-05T04:29:38.042Z
Learning: For testing holiday implementations in the vacanza/holidays repository, recommend using `from tests.common import CommonCountryTests` as the base class instead of directly using `unittest.TestCase` to maintain consistency with project conventions and leverage common test utilities.
Applied to files:
tests/test_utils.py
🧬 Code graph analysis (2)
tests/test_utils.py (2)
holidays/holiday_base.py (1)
HolidayBase(57-1304)holidays/utils.py (1)
list_long_weekends(442-480)
holidays/utils.py (1)
holidays/holiday_base.py (2)
get_nth_working_day(1099-1123)is_weekend(1148-1158)
🪛 Ruff (0.14.0)
tests/test_utils.py
227-227: Use a regular assert instead of unittest-style assertEqual
Replace assertEqual(...) with assert ...
(PT009)
231-231: Missing return type annotation for special method __init__
Add return type annotation: None
(ANN204)
231-231: Do not use mutable data structures for argument defaults
Replace with None; initialize within function
(B006)
239-239: Missing return type annotation for special method __contains__
Add return type annotation: bool
(ANN204)
248-248: Use a regular assert instead of unittest-style assertEqual
Replace assertEqual(...) with assert ...
(PT009)
258-258: Use a regular assert instead of unittest-style assertEqual
Replace assertEqual(...) with assert ...
(PT009)
264-264: Use a regular assert instead of unittest-style assertEqual
Replace assertEqual(...) with assert ...
(PT009)
270-270: Use a regular assert instead of unittest-style assertEqual
Replace assertEqual(...) with assert ...
(PT009)
276-276: Use a regular assert instead of unittest-style assertEqual
Replace assertEqual(...) with assert ...
(PT009)
281-281: Use a regular assert instead of unittest-style assertEqual
Replace assertEqual(...) with assert ...
(PT009)
holidays/utils.py
444-444: Boolean-typed positional argument in function definition
(FBT001)
444-444: Boolean default positional argument in function definition
(FBT002)
🔇 Additional comments (1)
tests/test_utils.py (1)
243-281: Good test coverage of core scenarios.The tests cover the main cases well: basic long weekends, multiple holidays, the inclusion flag, custom weekends, and empty input.
Consider adding an edge case test for long weekends that span year boundaries (e.g., Dec 31 + Jan 1) if you want even more thorough coverage, but what's here is solid.
There was a problem hiding this comment.
Actionable comments posted: 1
♻️ Duplicate comments (2)
holidays/utils.py (1)
442-446: Fix the function signature: importdate, use plainbool, make parameter keyword-only.Three issues here:
- Critical: The return type should be
list[list[date]], butdateisn't imported. Add it to line 26.Optional[bool]is redundant—boolcan't beNone. Usebooldirectly.- The boolean parameter should be keyword-only to prevent accidental positional usage.
Apply these changes:
-from datetime import timedelta +from datetime import date, timedeltadef list_long_weekends( instance: HolidayBase, + *, minimum_holiday_length: int = 3, - require_weekend_overlap: Optional[bool] = True, + require_weekend_overlap: bool = True, -) -> list: +) -> list[list[date]]:tests/test_utils.py (1)
243-281: Consider strengthening the test suite with invariant checks and edge cases.The current tests validate the happy path well. Adding a few defensive checks would make the suite more robust:
- Invariant assertion: Verify that all returned blocks satisfy
length >= minimum_holiday_length(currently hardcoded as 3 in tests).- Cross-year boundary: Add a test where a long weekend spans Dec 31 → Jan 1 to confirm the function handles year transitions correctly.
- Invalid subdivision: Mirror the
test_invalid_country_subdivision_raises_not_implementedpattern fromTestCountryHolidaysif applicable.Example additions:
def test_minimum_length_invariant(self): holidays = [date(2025, 7, 4), date(2025, 12, 26)] instance = MockHolidayBase(holidays) result = list_long_weekends(instance) # Verify all blocks are >= 3 days self.assertTrue(all(len(block) >= 3 for block in result)) def test_cross_year_boundary(self): # Jan 1, 2024 (Monday) → weekend Sat-Sun Dec 30-31, 2023 holidays = [date(2024, 1, 1)] instance = MockHolidayBase(holidays) result = list_long_weekends(instance) # Verify at least one block spans years self.assertTrue(any(block[0].year != block[-1].year for block in result if block))
📜 Review details
Configuration used: Path: .coderabbit.yaml
Review profile: ASSERTIVE
Plan: Pro
📒 Files selected for processing (2)
holidays/utils.py(2 hunks)tests/test_utils.py(3 hunks)
🧰 Additional context used
🧠 Learnings (6)
📚 Learning: 2025-09-16T09:44:45.875Z
Learnt from: PPsyrius
PR: vacanza/holidays#2881
File: holidays/countries/hungary.py:46-49
Timestamp: 2025-09-16T09:44:45.875Z
Learning: In the holidays library, using generic variable names like `name` for holiday names within country implementations is acceptable and follows established patterns across other country files, even when the same variable name might be reused for different holidays within the same method.
Applied to files:
holidays/utils.py
📚 Learning: 2025-09-04T08:54:35.319Z
Learnt from: PPsyrius
PR: vacanza/holidays#2881
File: tests/countries/test_albania.py:40-42
Timestamp: 2025-09-04T08:54:35.319Z
Learning: In the vacanza/holidays project test files, extract holiday name strings to local variables only when they are reused multiple times within the same test method (e.g., used in both assertHolidayName and assertNoHolidayName calls). When a holiday name is used only once, keep it inline rather than extracting it to a variable for the sake of consistency.
Applied to files:
holidays/utils.py
📚 Learning: 2025-09-14T17:17:14.387Z
Learnt from: PPsyrius
PR: vacanza/holidays#2881
File: tests/countries/test_saint_helena_ascension_and_tristan_da_cunha.py:209-209
Timestamp: 2025-09-14T17:17:14.387Z
Learning: In tests/countries/test_saint_helena_ascension_and_tristan_da_cunha.py, the explicit loop iteration pattern for subdivision-specific holiday checks (like Anniversary Day for TA subdivision) is intentionally preferred over using assertSubdivTa helper methods, as confirmed by PPsyrius.
Applied to files:
tests/test_utils.py
📚 Learning: 2025-04-05T04:47:27.213Z
Learnt from: PPsyrius
PR: vacanza/holidays#2416
File: tests/countries/test_turkmenistan.py:52-64
Timestamp: 2025-04-05T04:47:27.213Z
Learning: For holiday tests in the vacanza/holidays project, structure tests by individual holidays rather than by years. Each test method should focus on a specific holiday and test it across multiple years (from start_year through 2050) using helper methods like `assertHolidayName`. For fixed holidays, use generators like `(f"{year}-01-01" for year in range(1991, 2051))`. For movable holidays, specify individual dates for specific years followed by a range check.
Applied to files:
tests/test_utils.py
📚 Learning: 2025-03-23T16:59:25.794Z
Learnt from: PPsyrius
PR: vacanza/holidays#2362
File: tests/test_ical.py:31-40
Timestamp: 2025-03-23T16:59:25.794Z
Learning: In the holidays library's `TestIcalExporter` class, initializing `ICalExporter` with `None` is intentional. Using a mock object instead breaks tests because the constructor performs attribute validation with `getattr(self.holidays, "language", None)` which returns a mock with a mock object instead of `None`, causing validation failures. The approach isolates file operation tests from iCal generation logic.
Applied to files:
tests/test_utils.py
📚 Learning: 2025-04-05T04:29:38.042Z
Learnt from: PPsyrius
PR: vacanza/holidays#2416
File: tests/countries/test_turkmenistan.py:85-86
Timestamp: 2025-04-05T04:29:38.042Z
Learning: For testing holiday implementations in the vacanza/holidays repository, recommend using `from tests.common import CommonCountryTests` as the base class instead of directly using `unittest.TestCase` to maintain consistency with project conventions and leverage common test utilities.
Applied to files:
tests/test_utils.py
🧬 Code graph analysis (2)
holidays/utils.py (1)
holidays/holiday_base.py (2)
get_nth_working_day(1099-1123)is_weekend(1148-1158)
tests/test_utils.py (2)
holidays/holiday_base.py (1)
HolidayBase(57-1304)holidays/utils.py (1)
list_long_weekends(442-500)
🪛 Ruff (0.14.1)
holidays/utils.py
445-445: Boolean-typed positional argument in function definition
(FBT001)
445-445: Boolean default positional argument in function definition
(FBT002)
tests/test_utils.py
227-227: Use a regular assert instead of unittest-style assertEqual
Replace assertEqual(...) with assert ...
(PT009)
231-231: Missing return type annotation for special method __init__
Add return type annotation: None
(ANN204)
231-231: Do not use mutable data structures for argument defaults
Replace with None; initialize within function
(B006)
239-239: Missing return type annotation for special method __contains__
Add return type annotation: bool
(ANN204)
248-248: Use a regular assert instead of unittest-style assertEqual
Replace assertEqual(...) with assert ...
(PT009)
258-258: Use a regular assert instead of unittest-style assertEqual
Replace assertEqual(...) with assert ...
(PT009)
264-264: Use a regular assert instead of unittest-style assertEqual
Replace assertEqual(...) with assert ...
(PT009)
270-270: Use a regular assert instead of unittest-style assertEqual
Replace assertEqual(...) with assert ...
(PT009)
276-276: Use a regular assert instead of unittest-style assertEqual
Replace assertEqual(...) with assert ...
(PT009)
281-281: Use a regular assert instead of unittest-style assertEqual
Replace assertEqual(...) with assert ...
(PT009)
There was a problem hiding this comment.
Actionable comments posted: 1
♻️ Duplicate comments (1)
holidays/utils.py (1)
456-458: Clarify the parameter description.The current description is confusing given the default value of
True. Whenrequire_weekend_overlap=True, we include only blocks that overlap with weekends.Based on coding guidelines.
Apply this diff:
require_weekend_overlap: - Whether to include consecutive holidays that do not contain any weekend days. + Whether to include only consecutive holidays that overlap with a weekend. Defaults to True.
📜 Review details
Configuration used: Path: .coderabbit.yaml
Review profile: ASSERTIVE
Plan: Pro
📒 Files selected for processing (1)
holidays/utils.py(2 hunks)
🧰 Additional context used
🧠 Learnings (49)
📓 Common learnings
Learnt from: KJhellico
Repo: vacanza/holidays PR: 2774
File: tests/countries/test_liberia.py:15-16
Timestamp: 2025-08-08T14:37:03.045Z
Learning: When adding a new country in vacanza/holidays, also re-export it in holidays/countries/__init__.py (e.g., from .liberia import Liberia, LR, LBR) so tests and users can import from holidays.countries consistently.
Learnt from: PPsyrius
Repo: vacanza/holidays PR: 2416
File: tests/countries/test_turkmenistan.py:85-86
Timestamp: 2025-04-05T04:29:38.042Z
Learning: For testing holiday implementations in the vacanza/holidays repository, recommend using `from tests.common import CommonCountryTests` as the base class instead of directly using `unittest.TestCase` to maintain consistency with project conventions and leverage common test utilities.
Learnt from: PPsyrius
Repo: vacanza/holidays PR: 2416
File: tests/countries/test_turkmenistan.py:52-64
Timestamp: 2025-04-05T04:47:27.213Z
Learning: For holiday tests in the vacanza/holidays project, structure tests by individual holidays rather than by years. Each test method should focus on a specific holiday and test it across multiple years (from start_year through 2050) using helper methods like `assertHolidayName`. For fixed holidays, use generators like `(f"{year}-01-01" for year in range(1991, 2051))`. For movable holidays, specify individual dates for specific years followed by a range check.
Learnt from: PPsyrius
Repo: vacanza/holidays PR: 2537
File: tests/countries/test_finland.py:23-26
Timestamp: 2025-05-09T18:36:09.607Z
Learning: The holidays project prioritizes complete historical coverage in tests, verifying holidays from their first year of observance (e.g., 1853 for Finland) through future projections, rather than using shorter sliding windows.
Learnt from: PPsyrius
Repo: vacanza/holidays PR: 2881
File: tests/countries/test_argentina.py:375-375
Timestamp: 2025-09-03T16:49:35.246Z
Learning: In the holidays library, national holiday tests use self.full_range (or similar comprehensive year ranges) even when explicit test dates only show modern observance. This is intentional for correctness and comprehensive coverage, unlike subdivision-specific holidays which have explicit year boundaries based on known start dates.
Learnt from: PPsyrius
Repo: vacanza/holidays PR: 2601
File: holidays/countries/mongolia.py:140-146
Timestamp: 2025-06-15T11:50:44.366Z
Learning: The holidays library doesn't currently have helper functions like `_add_holiday_span` for adding consecutive multi-day holidays. Countries like Mongolia, Thailand, and Vietnam implement multi-day holiday spans using inline loops with `_timedelta(dt, delta)` pattern.
Learnt from: KJhellico
Repo: vacanza/holidays PR: 2783
File: tests/countries/test_eritrea.py:130-147
Timestamp: 2025-08-18T13:06:16.919Z
Learning: The `assertLocalizedHolidays` method in the vacanza/holidays project requires a complete list of all holidays from all categories (PUBLIC, GOVERNMENT, etc.), not just the holidays from the default category. This is a framework requirement for comprehensive localization testing.
Learnt from: PPsyrius
Repo: vacanza/holidays PR: 2881
File: tests/countries/test_brazil.py:28-30
Timestamp: 2025-09-10T14:35:54.603Z
Learning: In the holidays project, the test_no_holidays method should test ALL supported_categories (via categories=CountryClass.supported_categories) rather than just the default PUBLIC category, to ensure comprehensive validation that no holidays exist before start_year across any supported category including OPTIONAL and subdivision categories.
📚 Learning: 2025-08-11T13:48:45.953Z
Learnt from: PPsyrius
Repo: vacanza/holidays PR: 2794
File: holidays/calendars/ethiopian.py:13-13
Timestamp: 2025-08-11T13:48:45.953Z
Learning: The holidays library does not use `__all__` declarations in calendar modules (holidays/calendars/). Calendar files follow a standard pattern of defining constants and functions directly without explicit exports, similar to the convention used in country modules.
Applied to files:
holidays/utils.py
📚 Learning: 2025-06-16T12:28:31.641Z
Learnt from: PPsyrius
Repo: vacanza/holidays PR: 2632
File: holidays/countries/solomon_islands.py:95-98
Timestamp: 2025-06-16T12:28:31.641Z
Learning: Library-wide holiday patterns and their optimizations should be handled at the base class level (like InternationalHolidays) rather than documenting workarounds in individual country modules. This maintains separation of concerns and avoids documentation duplication.
Applied to files:
holidays/utils.py
📚 Learning: 2025-03-29T17:55:09.799Z
Learnt from: ankushhKapoor
Repo: vacanza/holidays PR: 2386
File: holidays/countries/nepal.py:29-34
Timestamp: 2025-03-29T17:55:09.799Z
Learning: In the holidays library, classes with multiple inheritance from various holiday groups (like ChristianHolidays, HinduCalendarHolidays, etc.) should initialize each parent class separately rather than using `super().__init__(*args, **kwargs)` because the parent classes have different parameter requirements. HolidayBase should receive the `*args, **kwargs` while other holiday group classes typically don't accept parameters like `observed`.
Applied to files:
holidays/utils.py
📚 Learning: 2025-08-26T21:29:47.753Z
Learnt from: KJhellico
Repo: vacanza/holidays PR: 2860
File: tests/common.py:365-372
Timestamp: 2025-08-26T21:29:47.753Z
Learning: In the holidays library, countries with Islamic holidays inherit directly from the IslamicHolidays class (e.g., `class Afghanistan(HolidayBase, InternationalHolidays, IslamicHolidays)`). The separate `_CustomIslamicHolidays` classes (like `AfghanistanIslamicHolidays`) are helper classes for specific date data, not the main country classes. Therefore, `isinstance(holidays_instance, IslamicHolidays)` is sufficient to detect all countries with Islamic holidays.
Applied to files:
holidays/utils.py
📚 Learning: 2025-06-18T10:07:58.780Z
Learnt from: PPsyrius
Repo: vacanza/holidays PR: 2642
File: holidays/countries/french_southern_territories.py:41-44
Timestamp: 2025-06-18T10:07:58.780Z
Learning: Territorial holiday classes that inherit from parent countries (like HolidaysAX from Finland, HolidaysSJ from Norway, HolidaysTF from France) follow a standard pattern of silently overriding self.subdiv in their _populate_public_holidays() method without validation, as this ensures they always use the correct subdivision code for their territory regardless of user input.
Applied to files:
holidays/utils.py
📚 Learning: 2025-09-17T15:16:16.192Z
Learnt from: KJhellico
Repo: vacanza/holidays PR: 2944
File: holidays/countries/myanmar.py:183-191
Timestamp: 2025-09-17T15:16:16.192Z
Learning: The special_public_holidays formatting pattern in the holidays codebase follows a consistent convention: single entries per year use flat tuple format like `2024: (MONTH, DAY, name)`, while multiple entries per year use tuple-of-tuples format like `2024: ((MONTH, DAY, name), (MONTH, DAY, name))`. This pattern is used consistently across all countries.
Applied to files:
holidays/utils.py
📚 Learning: 2025-09-16T04:11:33.513Z
Learnt from: PPsyrius
Repo: vacanza/holidays PR: 2928
File: holidays/countries/algeria.py:16-22
Timestamp: 2025-09-16T04:11:33.513Z
Learning: In the holidays library, country class base inheritance follows alphabetical ordering after HolidayBase. For example, Algeria correctly uses: HolidayBase, ChristianHolidays, HebrewCalendarHolidays, InternationalHolidays, IslamicHolidays (alphabetical after the required HolidayBase first position).
Applied to files:
holidays/utils.py
📚 Learning: 2025-04-05T04:29:38.042Z
Learnt from: PPsyrius
Repo: vacanza/holidays PR: 2416
File: tests/countries/test_turkmenistan.py:85-86
Timestamp: 2025-04-05T04:29:38.042Z
Learning: For testing holiday implementations in the vacanza/holidays repository, recommend using `from tests.common import CommonCountryTests` as the base class instead of directly using `unittest.TestCase` to maintain consistency with project conventions and leverage common test utilities.
Applied to files:
holidays/utils.py
📚 Learning: 2025-06-13T12:18:03.539Z
Learnt from: PPsyrius
Repo: vacanza/holidays PR: 2614
File: holidays/countries/guyana.py:78-90
Timestamp: 2025-06-13T12:18:03.539Z
Learning: The holidays codebase now uses the constructor signature pattern `__init__(self, *args, islamic_show_estimated: bool = True, **kwargs)` across country classes.
Applied to files:
holidays/utils.py
📚 Learning: 2025-07-02T10:22:33.053Z
Learnt from: KJhellico
Repo: vacanza/holidays PR: 2651
File: tests/countries/test_bonaire_sint_eustatius_and_saba.py:225-306
Timestamp: 2025-07-02T10:22:33.053Z
Learning: The `assertLocalizedHolidays` method in the vacanza/holidays project requires a complete list of all holidays from all subdivisions, not just subdivision-specific holidays. This is a framework requirement for proper localization testing.
Applied to files:
holidays/utils.py
📚 Learning: 2025-03-23T10:11:50.465Z
Learnt from: KJhellico
Repo: vacanza/holidays PR: 2354
File: holidays/countries/fiji.py:63-70
Timestamp: 2025-03-23T10:11:50.465Z
Learning: In the holidays library, the `SAT_SUN_TO_NEXT_MON_TUE` rule is specifically used for consecutive holidays (like Christmas Day and Boxing Day) to ensure they're observed on separate weekdays (Monday and Tuesday) when they fall on weekends, while `SAT_SUN_TO_NEXT_MON` is used as the default rule for other holidays.
Applied to files:
holidays/utils.py
📚 Learning: 2025-06-15T11:50:44.366Z
Learnt from: PPsyrius
Repo: vacanza/holidays PR: 2601
File: holidays/countries/mongolia.py:140-146
Timestamp: 2025-06-15T11:50:44.366Z
Learning: The holidays library doesn't currently have helper functions like `_add_holiday_span` for adding consecutive multi-day holidays. Countries like Mongolia, Thailand, and Vietnam implement multi-day holiday spans using inline loops with `_timedelta(dt, delta)` pattern.
Applied to files:
holidays/utils.py
📚 Learning: 2025-08-26T09:43:38.329Z
Learnt from: PPsyrius
Repo: vacanza/holidays PR: 2821
File: holidays/countries/tanzania.py:145-163
Timestamp: 2025-08-26T09:43:38.329Z
Learning: In the Tanzania holidays implementation, when multiple holidays fall on the same date (like Eid al-Fitr and Mwalimu Nyerere Day on 2007-10-14), the observed rule logic correctly applies to all holidays on that date. The SAT_SUN_TO_NEXT_MON_TUE rule for the first Eid day doesn't create issues with co-occurring holidays because in practice, such collisions occur on Sundays where both SAT_SUN_TO_NEXT_MON and SAT_SUN_TO_NEXT_MON_TUE rules yield identical results (both move to Monday).
Applied to files:
holidays/utils.py
📚 Learning: 2025-09-16T04:16:10.671Z
Learnt from: PPsyrius
Repo: vacanza/holidays PR: 2928
File: holidays/countries/algeria.py:143-154
Timestamp: 2025-09-16T04:16:10.671Z
Learning: When reviewing holiday implementations, always verify the actual legal text or official sources before making assumptions about holiday durations. Traditional religious observance patterns do not necessarily reflect what national laws specify for public holidays.
Applied to files:
holidays/utils.py
📚 Learning: 2025-04-23T09:59:19.886Z
Learnt from: PPsyrius
Repo: vacanza/holidays PR: 2490
File: holidays/countries/ethiopia.py:45-45
Timestamp: 2025-04-23T09:59:19.886Z
Learning: For the Ethiopia holidays class, it's appropriate to add a return type hint only to the `_is_leap_year` method to match the base class implementation in `holidays/holiday_base.py`, while keeping other methods without type hints to maintain consistency with other country implementations.
Applied to files:
holidays/utils.py
📚 Learning: 2025-04-05T04:47:27.213Z
Learnt from: PPsyrius
Repo: vacanza/holidays PR: 2416
File: tests/countries/test_turkmenistan.py:52-64
Timestamp: 2025-04-05T04:47:27.213Z
Learning: For holiday tests in the vacanza/holidays project, structure tests by individual holidays rather than by years. Each test method should focus on a specific holiday and test it across multiple years (from start_year through 2050) using helper methods like `assertHolidayName`. For fixed holidays, use generators like `(f"{year}-01-01" for year in range(1991, 2051))`. For movable holidays, specify individual dates for specific years followed by a range check.
Applied to files:
holidays/utils.py
📚 Learning: 2025-06-15T11:52:39.572Z
Learnt from: PPsyrius
Repo: vacanza/holidays PR: 2601
File: tests/countries/test_mongolia.py:128-156
Timestamp: 2025-06-15T11:52:39.572Z
Learning: In the vacanza/holidays project tests, when testing holidays that span multiple consecutive days across many years (like Mongolia's National Festival spanning July 11-13), prefer explicit for loops over complex nested generator expressions with unpacking. The explicit loops are more readable, easier to maintain, and better communicate the testing intent even though the Big O complexity is equivalent.
Applied to files:
holidays/utils.py
📚 Learning: 2025-06-10T12:43:10.577Z
Learnt from: ankushhKapoor
Repo: vacanza/holidays PR: 2601
File: holidays/calendars/mongolian.py:1-1
Timestamp: 2025-06-10T12:43:10.577Z
Learning: The holidays project's calendar files (in holidays/calendars/) follow a consistent pattern of NOT having module-level docstrings. They only use class-level docstrings for their main classes. When reviewing calendar files, maintain this consistency and do not suggest adding module docstrings.
Applied to files:
holidays/utils.py
📚 Learning: 2025-10-28T17:26:45.090Z
Learnt from: PPsyrius
Repo: vacanza/holidays PR: 3026
File: holidays/countries/spain.py:189-189
Timestamp: 2025-10-28T17:26:45.090Z
Learning: In the vacanza/holidays codebase, `_populate` methods (such as `_populate_public_holidays`, `_populate_subdiv_holidays`, and subdivision-specific methods like `_populate_subdiv_XX_public_holidays`) intentionally do not include return type annotations like `-> None`. This is a consistent pattern across country implementations (e.g., Germany, United States, Spain) and should not be changed even when static analysis tools like Ruff suggest adding them.
<!-- </add_learning>
Applied to files:
holidays/utils.py
📚 Learning: 2025-04-03T16:58:27.175Z
Learnt from: Wasif-Shahzad
Repo: vacanza/holidays PR: 2409
File: holidays/countries/qatar.py:27-46
Timestamp: 2025-04-03T16:58:27.175Z
Learning: In the holidays library, method names like `_add_holiday_2nd_tue_of_feb()` and `_add_holiday_1st_sun_of_mar()` use calendar constants internally through parent class implementations even when these constants don't appear directly in the file. Removing imports that seem unused based on a simple text search could break functionality.
Applied to files:
holidays/utils.py
📚 Learning: 2025-04-03T12:36:41.201Z
Learnt from: PPsyrius
Repo: vacanza/holidays PR: 2398
File: holidays/countries/guinea.py:73-77
Timestamp: 2025-04-03T12:36:41.201Z
Learning: In the Holidays library, comments explaining year restrictions for holidays should be placed above the year check conditional statement, not inside it. Example format:
```python
# reason why goes here
if start_year <= self._year <= end_year:
# Holiday name
self._add_holiday_function(tr("Holiday Name"))
```
Applied to files:
holidays/utils.py
📚 Learning: 2025-04-13T20:41:56.613Z
Learnt from: KJhellico
Repo: vacanza/holidays PR: 2386
File: holidays/countries/nepal.py:266-284
Timestamp: 2025-04-13T20:41:56.613Z
Learning: The Islamic holiday dates in the holidays library should only include officially verified dates, not predicted ones, to maintain accuracy. This is especially important for holidays that depend on lunar observations like Eid al-Fitr and Eid al-Adha.
Applied to files:
holidays/utils.py
📚 Learning: 2025-09-03T16:49:35.246Z
Learnt from: PPsyrius
Repo: vacanza/holidays PR: 2881
File: tests/countries/test_argentina.py:375-375
Timestamp: 2025-09-03T16:49:35.246Z
Learning: In the holidays library, national holiday tests use self.full_range (or similar comprehensive year ranges) even when explicit test dates only show modern observance. This is intentional for correctness and comprehensive coverage, unlike subdivision-specific holidays which have explicit year boundaries based on known start dates.
Applied to files:
holidays/utils.py
📚 Learning: 2025-04-13T19:10:31.502Z
Learnt from: KJhellico
Repo: vacanza/holidays PR: 2465
File: holidays/countries/suriname.py:219-251
Timestamp: 2025-04-13T19:10:31.502Z
Learning: The `_CustomIslamicHolidays` classes in this project contain only exact verified holiday dates from reliable sources, rather than calculated or estimated future dates. This is by design to ensure accuracy, particularly for religious holidays that may follow lunar calendars or depend on local observations.
Applied to files:
holidays/utils.py
📚 Learning: 2025-07-14T20:23:48.198Z
Learnt from: KJhellico
Repo: vacanza/holidays PR: 2654
File: holidays/countries/cabo_verde.py:133-141
Timestamp: 2025-07-14T20:23:48.198Z
Learning: The holidays library provides helper methods `_add_holiday_2nd_sun_of_may()` and `_add_holiday_3rd_sun_of_jun()` for adding holidays on the 2nd Sunday of May and 3rd Sunday of June respectively. These methods are used across multiple country implementations including Latvia, Finland, Belarus, Malaysia, Madagascar, and Cape Verde.
Applied to files:
holidays/utils.py
📚 Learning: 2025-06-15T15:24:53.055Z
Learnt from: KJhellico
Repo: vacanza/holidays PR: 2606
File: holidays/countries/faroe_islands.py:62-67
Timestamp: 2025-06-15T15:24:53.055Z
Learning: The `HolidayBase` class uses `__getattr__` to dynamically implement `_add_holiday_*` methods through pattern matching, including patterns like `_add_holiday_<n>_days_past_easter`, `_add_holiday_<month>_<day>`, and various weekday-relative patterns. Methods like `_add_holiday_26_days_past_easter` are not explicitly defined but are dynamically generated when called.
Applied to files:
holidays/utils.py
📚 Learning: 2025-09-16T09:44:45.875Z
Learnt from: PPsyrius
Repo: vacanza/holidays PR: 2881
File: holidays/countries/hungary.py:46-49
Timestamp: 2025-09-16T09:44:45.875Z
Learning: In the holidays library, using generic variable names like `name` for holiday names within country implementations is acceptable and follows established patterns across other country files, even when the same variable name might be reused for different holidays within the same method.
Applied to files:
holidays/utils.py
📚 Learning: 2025-09-04T08:54:35.319Z
Learnt from: PPsyrius
Repo: vacanza/holidays PR: 2881
File: tests/countries/test_albania.py:40-42
Timestamp: 2025-09-04T08:54:35.319Z
Learning: In the vacanza/holidays project test files, extract holiday name strings to local variables only when they are reused multiple times within the same test method (e.g., used in both assertHolidayName and assertNoHolidayName calls). When a holiday name is used only once, keep it inline rather than extracting it to a variable for the sake of consistency.
Applied to files:
holidays/utils.py
📚 Learning: 2025-07-02T18:21:59.302Z
Learnt from: KJhellico
Repo: vacanza/holidays PR: 2608
File: tests/countries/test_saint_vincent_and_the_grenadines.py:162-178
Timestamp: 2025-07-02T18:21:59.302Z
Learning: In the Saint Vincent and the Grenadines holiday tests, for holidays without observed rules that only require a single assertHolidayName call, pass the holiday name directly as a string literal rather than storing it in a variable first for cleaner, more concise code.
Applied to files:
holidays/utils.py
📚 Learning: 2025-08-26T14:43:53.605Z
Learnt from: KJhellico
Repo: vacanza/holidays PR: 2851
File: docs/holiday_categories.md:272-282
Timestamp: 2025-08-26T14:43:53.605Z
Learning: In the holidays library documentation, it's strongly advisable to recommend the use of constants from holidays.constants (e.g., PUBLIC, CATHOLIC) instead of direct string values when specifying holiday categories, as constants provide better type safety, IDE support, and prevent typos.
Applied to files:
holidays/utils.py
📚 Learning: 2025-04-23T09:22:41.753Z
Learnt from: PPsyrius
Repo: vacanza/holidays PR: 2489
File: holidays/countries/sao_tome_and_principe.py:86-88
Timestamp: 2025-04-23T09:22:41.753Z
Learning: For holiday definitions in the holidays package, keep comments simple with just the holiday name (e.g., "# Independence Day.") rather than including dates or historical context, as the function names already encode the date information.
Applied to files:
holidays/utils.py
📚 Learning: 2025-09-18T07:01:12.236Z
Learnt from: PPsyrius
Repo: vacanza/holidays PR: 2942
File: holidays/countries/south_africa.py:91-98
Timestamp: 2025-09-18T07:01:12.236Z
Learning: In the holidays library South Africa implementation, inline ternary operators for holiday name selection (like "Republic Day" if self._year >= 1961 else "Union Day") are intentionally kept inline rather than extracted to separate variables, as this structure is designed in preparation for future localization (l10n) support where the contextual relationship between conditions and translatable strings needs to be preserved.
Applied to files:
holidays/utils.py
📚 Learning: 2025-07-24T15:21:31.632Z
Learnt from: PPsyrius
Repo: vacanza/holidays PR: 2750
File: tests/countries/test_germany.py:46-46
Timestamp: 2025-07-24T15:21:31.632Z
Learning: In the holidays project test files, the standard method name for testing the absence of holidays is `test_no_holidays`, not more descriptive names like `test_no_holidays_before_1990`. This is a consistent naming convention across country test files like France and Germany.
Applied to files:
holidays/utils.py
📚 Learning: 2025-06-14T20:43:15.370Z
Learnt from: KJhellico
Repo: vacanza/holidays PR: 2631
File: holidays/countries/sint_maarten.py:94-95
Timestamp: 2025-06-14T20:43:15.370Z
Learning: The `_add_*` helper methods in the holidays library (such as `_add_christmas_day_two()`, `_add_labor_day()`, etc.) don't have default holiday names, so the name parameter should always be explicitly specified when calling these methods.
Applied to files:
holidays/utils.py
📚 Learning: 2025-07-10T03:36:16.461Z
Learnt from: PPsyrius
Repo: vacanza/holidays PR: 2706
File: holidays/countries/cayman_islands.py:80-97
Timestamp: 2025-07-10T03:36:16.461Z
Learning: In the holidays library, date dictionaries that map years to specific dates (like queens_birthday_dates, special holiday dates, etc.) are typically defined within the _populate_public_holidays method rather than as module-level constants. This is the established library-wide pattern and should be maintained for consistency.
Applied to files:
holidays/utils.py
📚 Learning: 2025-09-17T09:07:56.459Z
Learnt from: PPsyrius
Repo: vacanza/holidays PR: 2881
File: tests/countries/test_paraguay.py:134-139
Timestamp: 2025-09-17T09:07:56.459Z
Learning: In the vacanza/holidays project, for holidays that start from a specific year (not the country's start_year), the standard pattern is to use `range(specific_year, self.end_year)` rather than `self.full_range` with year conditions. This maintains consistency across the codebase and clearly separates the holiday period from the pre-holiday period using `assertNoHolidayName(name, range(self.start_year, specific_year))`.
Applied to files:
holidays/utils.py
📚 Learning: 2025-09-17T09:07:56.459Z
Learnt from: PPsyrius
Repo: vacanza/holidays PR: 2881
File: tests/countries/test_paraguay.py:134-139
Timestamp: 2025-09-17T09:07:56.459Z
Learning: In the vacanza/holidays project, when testing holidays that start from a specific year (not the country's start_year), the standard pattern is to use `range(specific_year, self.end_year)` for the holiday dates and `assertNoHolidayName(name, range(self.start_year, specific_year))` for the gap period. Using `self.full_range` with year conditions like `if year >= specific_year` is not the established pattern and would be inconsistent with the codebase.
Applied to files:
holidays/utils.py
📚 Learning: 2025-09-14T04:41:10.139Z
Learnt from: PPsyrius
Repo: vacanza/holidays PR: 2881
File: tests/countries/test_south_africa.py:22-22
Timestamp: 2025-09-14T04:41:10.139Z
Learning: South Africa's observed holiday system only started in 1995, so in tests/countries/test_south_africa.py, using years_non_observed=range(1995, 2050) is intentional to limit testing to years where observed holidays actually exist, improving both correctness and performance.
Applied to files:
holidays/utils.py
📚 Learning: 2025-08-03T13:48:11.910Z
Learnt from: KJhellico
Repo: vacanza/holidays PR: 2777
File: holidays/countries/gambia.py:120-122
Timestamp: 2025-08-03T13:48:11.910Z
Learning: When reviewing holiday implementations in the holidays library, defer to the maintainers' choice of start years for specific holiday policies, as they likely have access to more reliable primary sources and official documentation than what can be found through web searches.
Applied to files:
holidays/utils.py
📚 Learning: 2025-05-09T18:36:09.607Z
Learnt from: PPsyrius
Repo: vacanza/holidays PR: 2537
File: tests/countries/test_finland.py:23-26
Timestamp: 2025-05-09T18:36:09.607Z
Learning: The holidays project prioritizes complete historical coverage in tests, verifying holidays from their first year of observance (e.g., 1853 for Finland) through future projections, rather than using shorter sliding windows.
Applied to files:
holidays/utils.py
📚 Learning: 2025-06-14T11:04:31.180Z
Learnt from: PPsyrius
Repo: vacanza/holidays PR: 2609
File: holidays/countries/nauru.py:57-60
Timestamp: 2025-06-14T11:04:31.180Z
Learning: In the holidays library, the base `HolidayBase._populate()` method already includes a guard clause that prevents holiday population methods like `_populate_public_holidays()` from being called when the year is before `start_year` or after `end_year`. Therefore, individual country implementations do not need to add their own guard clauses for years before independence or other start dates.
Applied to files:
holidays/utils.py
📚 Learning: 2025-07-09T21:16:35.145Z
Learnt from: KJhellico
Repo: vacanza/holidays PR: 2623
File: tests/countries/test_christmas_island.py:136-146
Timestamp: 2025-07-09T21:16:35.145Z
Learning: In Christmas Island's holiday implementation, the test_christmas_day method cannot use assertNoNonObservedHoliday because in some years observed Christmas Day overlaps with Boxing Day when both holidays are moved due to weekend conflicts, causing the standard non-observed holiday check to fail inappropriately.
Applied to files:
holidays/utils.py
📚 Learning: 2025-06-06T14:40:31.932Z
Learnt from: KJhellico
Repo: vacanza/holidays PR: 2593
File: holidays/countries/senegal.py:66-110
Timestamp: 2025-06-06T14:40:31.932Z
Learning: In the holidays library, within the _populate_public_holidays method, holidays should be arranged by calendar type (Islamic holidays first, then Gregorian holidays) without additional type grouping comments. The organization by calendar type is sufficient and follows the project's established conventions.
Applied to files:
holidays/utils.py
📚 Learning: 2025-03-04T11:32:45.095Z
Learnt from: PPsyrius
Repo: vacanza/holidays PR: 2323
File: holidays/countries/macau.py:407-461
Timestamp: 2025-03-04T11:32:45.095Z
Learning: In the holidays library, the standard approach for organizing static holidays is to use separate dictionaries for different categories (like `special_government_holidays`, `special_mandatory_holidays`, and `special_public_holidays`), which are utilized by syntactic sugar methods to pick up the appropriate holidays based on the selected category.
Applied to files:
holidays/utils.py
📚 Learning: 2025-03-04T11:32:45.095Z
Learnt from: PPsyrius
Repo: vacanza/holidays PR: 2323
File: holidays/countries/macau.py:407-461
Timestamp: 2025-03-04T11:32:45.095Z
Learning: In the holidays library, the standard approach for organizing static holidays is to use separate dictionaries for different categories (`government`, `mandatory`, and `public`), which are utilized by syntactic sugar methods.
Applied to files:
holidays/utils.py
📚 Learning: 2025-04-08T14:46:10.656Z
Learnt from: KJhellico
Repo: vacanza/holidays PR: 2437
File: holidays/countries/bhutan.py:27-30
Timestamp: 2025-04-08T14:46:10.656Z
Learning: For country classes in the holidays library, there's no need to explicitly specify `supported_categories = (PUBLIC,)` when PUBLIC is the only category being used, as it's already the default category inherited from HolidayBase.
Applied to files:
holidays/utils.py
📚 Learning: 2025-08-21T04:56:03.780Z
Learnt from: PPsyrius
Repo: vacanza/holidays PR: 2843
File: holidays/countries/burundi.py:63-101
Timestamp: 2025-08-21T04:56:03.780Z
Learning: In the holidays library, countries with localization support DO use tr() wrappers around holiday names when calling _add_* methods. This is the correct pattern for l10n-enabled country implementations, contrary to previous learning about translation being handled internally by _add_* methods.
Applied to files:
holidays/utils.py
📚 Learning: 2025-09-04T09:48:11.738Z
Learnt from: PPsyrius
Repo: vacanza/holidays PR: 2881
File: tests/countries/test_andorra.py:29-31
Timestamp: 2025-09-04T09:48:11.738Z
Learning: In the holidays library, when accessing supported_categories in test files, the library-wide standard is to use the full class name (e.g., Andorra.supported_categories) rather than aliases (e.g., AD.supported_categories), maintaining consistency across the codebase.
Applied to files:
holidays/utils.py
🧬 Code graph analysis (1)
holidays/utils.py (2)
holidays/calendars/gregorian.py (1)
_timedelta(37-42)holidays/holiday_base.py (2)
get_nth_working_day(1100-1124)_is_weekend(876-883)
🪛 Ruff (0.14.3)
holidays/utils.py
444-444: Boolean default positional argument in function definition
(FBT002)
444-444: Undefined name Optional
(F821)
🔇 Additional comments (3)
holidays/utils.py (3)
21-21: LGTM!Correctly exposes the new utility in the public API.
28-28: LGTM!Import is necessary for date arithmetic in the new function and follows the established pattern.
464-490: Implementation looks solid.The algorithm correctly:
- Expands each holiday to its surrounding non-working days
- Filters by minimum length
- Checks weekend overlap when required
- Avoids duplicate processing
The logic is clear and follows established patterns from the codebase.
bf641e3
utils::list_long_weekends function to find holiday-based long weekendsutils::list_long_breaks function to find consecutive holidays
arkid15r
left a comment
There was a problem hiding this comment.
@AryaPhansalkar thanks for working on this, it's a great improvement 👍
@KJhellico @PPsyrius I've update this PR with some naming changes (no logic change). I also considere day off vs holiday in this context. I'm looking forward to your suggestions on the current code improvements (if any).
I.e. |
Co-authored-by: ~Jhellico <[email protected]>
|
The pleasure is mine @arkid15r |
|
And also thank you for all the suggestions @KJhellico and @PPsyrius they were really helpful |



Proposed change
Resolves #2422
Type of change
holidaysfunctionality in general)Checklist
make checklocally; all checks and tests passed.