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


Help: OASIS Mailing Lists Help | MarkMail Help

odata message

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

Subject: [OASIS Issue Tracker] (ODATA-1103) Special values of temporal types (public comment c201708e0003)

Ralf Handl created ODATA-1103:

             Summary: Special values of temporal types (public comment c201708e0003)
                 Key: ODATA-1103
                 URL: https://issues.oasis-open.org/browse/ODATA-1103
             Project: OASIS Open Data Protocol (OData) TC
          Issue Type: Task
          Components: ABNF Construction Rules, CSDL JSON , CSDL XML, URL Conventions
    Affects Versions: V4.01_CSD02, V4.01_CSD01
            Reporter: Ralf Handl
             Fix For: V4.01_CS01

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):

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.


This message was sent by Atlassian JIRA

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