-
Notifications
You must be signed in to change notification settings - Fork 572
Python conversion of xsd:gYear and xsd:gYearMonth typed Literals should not return datetime.date objects #3078
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Comments
this could be related to #2419 |
I dont expect any set behaviour from |
Thanks for input and sorry for my late reply. As mentioned in the initial post, imo there is no way to express I think returning an |
I took a quick look at the I.e. my plan would be to change I think it would be best to outsource the responsibility for XSD-type validation to some external tool, either xmlschema or |
Actually, for simple XSD types like |
The change adds a code path for handling xsd:gYear/xsd:gYearMonth-typed RDF literals to `rdfproxy.sparqlwrapper.SPARQLWrapper._get_bindings_from_json_response`. See the corresponding RDFLib issue: RDFLib/rdflib#3078 Concerns #232.
The change adds a code path for handling xsd:gYear/xsd:gYearMonth-typed RDF literals to `rdfproxy.sparqlwrapper.SPARQLWrapper._get_bindings_from_json_response`. See the corresponding RDFLib issue: RDFLib/rdflib#3078 Concerns #232.
Actually you are totally correct. gYear and gMonth is literally not supposed to be castable to datetime as seen by a table here in this documentation to xpath-functions. |
Issue RDFLib#3078 reports, that toPython-casting of xsd:gYear and xsd:gYearMonth to datetime objects is not possible, as there is no appropriate Python equivalence for those types. The current implementation casts xsd:gYear and xsd:gYearMonth to datetime objects assuming Jannuary 1st for xsd:gYear and the 1st day of the given month for xsd:gYearMonth. This is plain wrong. The change re-implements parse_xsd_gyear and parse_xsd_gyearmonth so that XSD-types are checked against a regex and gYear and gYearMonth are not converted to Python datetime objects anymore but simply return the value unchanged after checking.
Issue RDFLib#3078 reports, that toPython-casting of xsd:gYear and xsd:gYearMonth to datetime objects is not possible, as there is no appropriate Python equivalence for those types. The current implementation casts xsd:gYear and xsd:gYearMonth to datetime objects assuming Jannuary 1st for xsd:gYear and the 1st day of the given month for xsd:gYearMonth. This is plain wrong. The change removes casting to datetime objects in rdflib.Literal.toPython for xsd:gYear and xsd:gYearMonth. Closes RDFLib#3078 .
PR pending: #3115 This is still a draft because I would like to add docs for this. |
Issue RDFLib#3078 reports, that rdflib.Literal.toPython casting of xsd:gYear and xsd:gYearMonth to datetime objects is not possible, as there is no appropriate Python equivalence for those types. The current implementation casts xsd:gYear and xsd:gYearMonth to datetime objects assuming January 1st for xsd:gYear and the 1st day of the given month for xsd:gYearMonth. This is plain wrong. The change removes casting to datetime objects in rdflib.Literal.toPython for xsd:gYear and xsd:gYearMonth. Closes RDFLib#3078 .
Currently, the
rdflib.Literal.toPython
conversion ofxsd:gYear
andxsd:gYearMonth
-typedrdflib.Literals
returnsdatetime.date
objects with the day (xsd:gYearMonth
) or day and month (xsd:gYear
) arguments set to 1.I think this is plain wrong,
xsd:gYear
is not equivalent todatetime.date(2025, 1, 1)
.Note that issue #1379 addressed this already, but focused more on a serialization problem and was then closed without really discussing the datetime conversion of
xsd:gYear
andxsd:gYearMonth
.A practical solution for this would be to just return an
rdflib.Literal
with thedatatype
property set; this way, the XSD type information would still be available.I would be happy to implement the necessary changes and open a PR if this the suggested/some solution is agreed upon.
The text was updated successfully, but these errors were encountered: