Not able to use just Date in $filter

[ceouten]

This worked in Odata v6 but is now throwing an error in v7

$filter=CreateDateUtc gt 2014-06-23

In the above example CreateDateUtc would be a DateTimeOffset. I'm not sure what changed between versions that broke this functionality.

The error returned is "The query specified in the URI is not valid. No coercion operator is defined between types 'Microsoft.OData.Edm.Date' and 'System.Nullable`1[System.DateTimeOffset]'."

I tried upgrading to v7.5 but that didn't fix the issue.

I'm fine with writing custom code to handle this but I'm not exactly where I should start. I tried using a custom ODataUriResolver where I override the PromoteBinaryOperandTypes method but that didn't seem to work. Is the best way to make a custom EnableQueryAttribute where I modify the actual query?

Any guidance would be extremely helpful.

[xuzhg]

@ceouten It looks your problem is similar to OData/WebApi#1473

Please refer to OData/WebApi#1473 and get the information. Thanks.

[ceouten]

@xuzhg I would prefer not to have to ask all my consumers to change how they are currently using my REST API because I want to upgrade an internal framework. Is there a way I can implement the proposed fix as a custom ExpressionBinder?

[csbowe]

I've run into the same issue and like @ceouten I have a public-facing API being consumed where folks are used to being able to filter by a date only, without the date() syntax. We cannot require consumers to change their integrations, so our options are either a) find a workaround we can implement internally or c) plead for this breaking change to be fixed in the next odata version or c) do not upgrade odata to the latest version and eventually move away from it.

[biaol-odata]

Add reference to OData/WebApi #136, for broader context.

[NetTecture]

It is not "used to" only. OData is an open standard. People may be using toolkits - like excel or PowerBI. Not accepting a by standard well formed URL is a bug, and "rewrite your external tools" is not an answer.

[NetTecture]

Acutally the problem is worse - it seems someone did not want t owrite any unit test for parsing literals of any kind and now as a result of that (plus not really well done programming) quite a number of literal types do not work.

GUID's are also not parsed properly.

Someone obviously did not write or want to write unit tests for literal parsing and then there was a sloppy programming job.

Now a number of iterals are not properly converted and now you seriously xpect other people to rewrite their access libraries to adhere to non-standard Odata?