-
Notifications
You must be signed in to change notification settings - Fork 88
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
pyodata 1.8.0 - Error if Edm.DateTimeOffset is not set #195
Comments
Here is the server response that leads to this error: Transcript.txt |
I do not know how to work around this and whether it would be needed in any case. Need to look up if OData allows specifying dates in year 0 or before. For now, I will fix this by defaulting to a suitable default year (1970?). |
Default value was broken in several ways: - Month 0 does not exist - Day 0 does not exist - Year 0 can not be handled by Python datetime The new default value is copied from Edm.DateTime.
Did not dig into this, but it seems like we have never been able to deal with values before 01 Jan 0001 anyway. Went on to create PR #197. |
Default value was broken in several ways: - Month 0 does not exist - Day 0 does not exist - Year 0 can not be handled by Python datetime
Default value was broken in several ways: - Month 0 does not exist - Day 0 does not exist - Year 0 can not be handled by Python datetime
Default value was broken in several ways: - Month 0 does not exist - Day 0 does not exist - Year 0 can not be handled by Python datetime
This should be fixed in #195 and part of release 1.9.0. Please reopen if still reproducible. |
This issue is based on an issue I got on a library that uses pyodata (metaodi/swissparlpy#17)
Some calls fail when pyodata tries to parse dates:
And the trace is the following:
I'm not 100% I understand everything that happens, but to me it seems, that in pyodata/v2/service.py (Line 768) the defined null_value is passed to
from_literal
and the null_value of Edm.DateTimeOffset is set to'datetimeoffset\'0000-00-00T00:00:00Z\''
The new code introduced in #184 doesn't seem to check for this case.
My current workaround is this to monkey patch this:
But maybe this is not the best place to fix this issue.
cc @rettichschnidi
The text was updated successfully, but these errors were encountered: