Special values of temporal types (public comment c201708e0003)

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 / ODATA-1091

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):
https://stackoverflow.com/questions/8011914/how-to-represent-end-of-time-in-a-database

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.

Steve