model.datatypes: Fix gYear/gYearMonth validation#586
Merged
Conversation
…ear values Previously, `_parse_xsd_gyear` and `_parse_xsd_gyearmonth` in `datatypes.py` reject values with more than 4 digits or negative signs. Now, the regexes support an optional minus sign and 4+ digits, and the parsers correctly handle the sign from `match[1]`. Unit tests were added. Fixes eclipse-basyx#566
Member
|
I know I proposed it so myself in the issue, that this only needs adaptation of the parsing. However I just realized that this would now parse and serialize the BCE times perfectly fine, but break when trying to convert them into I think this may be fine: Someone who just wants to store the value has no problem, it only becomes a problem when you want to perfom calculations on the value, but maybe should adapt the error message when trying to convert? Let's talk about this in the next dev meeting. |
s-heppner
reviewed
Jul 14, 2026
…nd fix bug in GMonthDay
The previous commit added a clear error message for negative years, but placed it in `GYear.from_date` and `GYearMonth.from_date`. That branch is unreachable: a Python `datetime.date` can never hold a negative year, so `from_date` never receives one, and the G-Class constructors accept negative years without raising. Negative years actually fail in the opposite direction, in `into_date`, which builds a `Date` and hits Python's cryptic "year -2001 is out of range" error. This change moves the clear error message from `from_date` to `into_date` on `GYear` and `GYearMonth`, and adds a test covering the negative-year case.
s-heppner
approved these changes
Jul 15, 2026
s-heppner
changed the title
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Previously,
GYEAR_REandGYEARMONTH_REonly matched exactly four digits and did not allow a leading minus sign. This rejected valid XSD values such as years with more than four digits (e.g. "20000") and negative years (e.g. "-2001"), even though the XSD spec permits both.Additionally,
GMonthDay.from_date(...)passeddate.yearinstead ofdate.dayto the constructor, andinto_date(...)onGYear/GYearMonthraised Python's cryptic "year -2001 is out of range" error for negative years, sincedatetime.datedoes not support them.This change widens the regular expressions to accept any number of digits and an optional leading minus sign, fixes the
GMonthDay. from_date(...)argument order bug, and makesinto_date(...)raise a clearValueErrorwhen called on a G-Class with a negative year.Fixes #566