OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

odata-comment message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: RE: [odata-comment] Special values of numeric types


Hi Steve,

 

Thanks for your feedback.

 

I’ve created https://issues.oasis-open.org/browse/ODATA-1103 to track this additional aspect of -INF/INF for Edm.DateTimeOffset and Edm.Date.

 

Thanks

Ralf

 

From: Steve Lay [mailto:steve.w.lay@gmail.com]
Sent: Donnerstag, 10. August 2017 22:29
To: Handl, Ralf <ralf.handl@sap.com>
Cc: odata-comment@lists.oasis-open.org
Subject: Re: [odata-comment] Special values of numeric types

 

These changes address the issue with integers.

 

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.

 

Steve



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]