Affects Version/s: V4.01_CSD02, V4.01_CSD01
Revise proposal from 8/24/2017 meeting:
I propose we resolve OData-1103 by removing the support for INF and -INF for the temporal data types added in OData 4.01.
https://tools.oasis-open.org/version-control/browse/wsvn/odata/trunk/4.01%20spec/ABNF/odata-abnf-testcases.xml?op=diff&rev=1070https://www.oasis-open.org/committees/download.php/61629/odata-v4.01-wd03-part2-url-conventions-2017-09-22.docx https://tools.oasis-open.org/version-control/browse/wsvn/odata/trunk/4.01%20spec/ABNF/odata-abnf-construction-rules.txt?op=diff&rev=1070 https://tools.oasis-open.org/version-control/browse/wsvn/odata/trunk/4.01%20spec/ABNF/odata-abnf-testcases.xml?op=diff&rev=1070 https://www.oasis-open.org/committees/download.php/61625/odata-csdl-json-v4.01-wd02-2017-09-22.docx https://www.oasis-open.org/committees/download.php/61626/odata-csdl-xml-v4.01-wd03-2017-09-22.docx
Public Review Comment https://lists.oasis-open.org/archives/odata-comment/201708/msg00003.html
Follow-up to https://lists.oasis-open.org/archives/odata-comment/201707/msg00002.html /
The addition of INF/-INF for date types does introduce a new ambiguity in the primitiveLiteral syntax though.
If I parse the value INF in an expression I don't know if it is meant to be a numeric or a Date (or DateTimeOffset) type. Numeric types can all be cast to each other (within limits) so it doesn't actually matter but in the proposed 4.01 my parser is likely to parse INF as doubleValue (or decimalValue now) and then, when attempting to use it in a context where a DateTimeOffset is required, the cast will fail and result in NULL.
The guidance here is interesting on whether to attempt INF/-INF with dates (look past the accepted answer too):
PostgreSQL does use Infinity for both date types but (curiously) these special values appear to be timestamps internally (and will cast to Date as required) whereas the equivalent numeric values must be quoted (as strings) and presumably rely on cast from string to numeric.
It's a tight corner! The trouble is that primitiveLiteral has set out to enable numeric types and date types to be parsable without any special quoting which rules out any common representations (of non-castable types).
Given that you have maxdatetime and mindatetime as functions are you now going to have maxdatetime() return INF? Or is there now a value of DateTimeOffset that compares greater than maxdatetime()?
Referring to the SO thread, it feels like you are trying to implement both patterns at once. If you're committed to maxdatetime I suggest sticking with that. Otherwise, promote maxdatetime/mindatetime to being a special value (of type DateTimeOffset) instead of being a function. You will need maxdate and mindate too.