Open rlskoeser opened 2 days ago
[!IMPORTANT]
Review skipped
Auto reviews are disabled on base/target branches other than the default branch.
Please check the settings in the CodeRabbit UI or the
.coderabbit.yaml
file in this repository. To trigger a single review, invoke the@coderabbitai review
command.You can disable this status message by setting the
reviews.review_status
tofalse
in the CodeRabbit configuration file.
The pull request introduces several changes, primarily focusing on the addition of the HijriDateConverter
class and related components for converting Hijri calendar dates to Gregorian dates. The pyproject.toml
file is updated to modify dependencies, including the addition of convertdate
and a change in the lark
dependency. New grammar specifications for parsing Hijri dates are also introduced, along with tests to validate the new functionality.
File Path | Change Summary |
---|---|
pyproject.toml |
Updated dependencies: added convertdate , changed lark to lark[interegular] . |
src/undate/converters/calendars/__init__.py |
Added HijriDateConverter to __all__ for public API. |
src/undate/converters/calendars/hijri/__init__.py |
Imported HijriDateConverter and updated __all__ to include it. |
src/undate/converters/calendars/hijri/converter.py |
Introduced HijriDateConverter class with a parse method for converting Hijri dates. |
src/undate/converters/calendars/hijri/hijri.lark |
Added grammar rules for parsing Hijri dates, including definitions for years, months, and days. |
src/undate/converters/calendars/hijri/parser.py |
Introduced parser.py to initialize hijri_parser using hijri.lark . |
src/undate/converters/calendars/hijri/transformer.py |
Added HijriDateTransformer class for transforming Hijri date parse trees. |
src/undate/converters/edtf/edtf.lark |
Updated day rule regex to include the 20th day of the month. |
src/undate/converters/edtf/parser.py |
Changed import from os.path to pathlib , removed commented-out test cases. |
src/undate/undate.py |
Updated comments and type annotations in UndateInterval class. |
tests/test_converters/test_calendars/test_hijri/test_hijri_converter.py |
Added tests for HijriDateConverter functionality. |
tests/test_converters/test_calendars/test_hijri/test_hijri_parser.py |
Introduced tests for hijri_parser to validate various Hijri date formats. |
tests/test_converters/test_calendars/test_hijri/test_hijri_transformer.py |
Added tests for HijriDateTransformer class and its conversion logic. |
pyproject.toml
file and its dependencies may relate to the updates in the numpy
handling in PR #84, as both involve modifications to dependencies and project configuration.pyproject.toml
file in the main PR aligns with the consolidation efforts in PR #88, which also focuses on streamlining project configuration and documentation.🐰 In the garden where dates bloom bright,
A converter hops with all its might.
From Hijri to Gregorian, it leaps with glee,
Transforming dates for you and me!
With tests in place, it’s sure to shine,
A joyful change, oh how divine! 🌼
Thank you for using CodeRabbit. We offer it for free to the OSS community and would appreciate your support in helping us grow. If you find it useful, would you consider giving us a shout-out on your favorite social media?
@coderabbitai review
Should a month or year in another calendar be represented in a single Undate or should it always be a UndateInterval?
I would find it more elegant if non-Gregorian months or years could also be represented as a single Undate. Does that make other Undate functions too complex? The default constructor assumes Gregorian and it would have to be changed.
Does this change what precision=year means? Is it too weird to have an Undate "year" based on the Gregorian calendar where the Gregorian text representation does not align on a year? Maybe we should have a "non-gregorian" flag for cases when you really care about this.
Should a month or year in another calendar be represented in a single Undate or should it always be a UndateInterval?
I would find it more elegant if non-Gregorian months or years could also be represented as a single Undate. Does that make other Undate functions too complex? The default constructor assumes Gregorian and it would have to be changed.
Does this change what precision=year means? Is it too weird to have an Undate "year" based on the Gregorian calendar where the Gregorian text representation does not align on a year? Maybe we should have a "non-gregorian" flag for cases when you really care about this.
@robcast these are fantastic questions and I like where you are going with it. I had been intending to add a calendar property to Undate
so that we could be explicit about what calendar the date is in. Can you help me sketch out what it would look like and how it would operate? I agree that this would be much more elegant and powerful.
Here's what I'm thinking based on what you're proposing: when parsing a Hijri date, instead of converting to Gregorian before creating Undate objects, we initialize the Undate with numeric year, month, day values and a calendar. This allows us to keep them a single Undate instead of an UndateInterval, and also preserves the date precision logic. There are lots of benefits to this approach. If we do that, then would we calculate the earliest/latest dates in the Hijri calendar or Gregorian? Or have options for both? Or maybe the comparison logic needs to be calendar aware and we only do the conversion when it matters or is explicitly requested? I'm leaning towards this last option, but let me know what you think!
decisions from discussion with @robcast :
related to #10
todo
Questions:
Summary by CodeRabbit
Release Notes
New Features
HijriDateConverter
for converting Hijri calendar dates to Gregorian dates.HijriDateTransformer
for transforming parsed Hijri dates intoUndate
orUndateInterval
objects.Bug Fixes
Tests
HijriDateConverter
,hijri_parser
, andHijriDateTransformer
to ensure functionality and error handling.