[jira] [Commented] (OLINGO-1173) CLONE - EdmDateTime format validation while parsing

["Punith DG (JIRA)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/OLINGO-1173?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16148508#comment-16148508 ] 

Punith DG commented on OLINGO-1173:
-----------------------------------

{{Hi,

I see this precision issue is solved in 2.0.9 build. But still there is an issue. It doesn't match the date time which contains Z at end. e.g., 2016-03-22T08:36:24Z

If we add a match to allow Z at the end, it would solve the issue completely. It is a very small fix so I think you won't mind fixing this.

Current regex - (\\p{Digit}{1,4})-(\\p{Digit}{1,2})-(\\p{Digit}{1,2})T(\\p{Digit}{1,2}):(\\p{Digit}{1,2})(?::(\\p{Digit}{1,2})(\\.(\\p{Digit}{0,9}?)0*)?)?

Fix regex - (\\p{Digit}{1,4})-(\\p{Digit}{1,2})-(\\p{Digit}{1,2})T(\\p{Digit}{1,2}):(\\p{Digit}{1,2})(?::(\\p{Digit}{1,2})(\\.(\\p{Digit}{0,9}?)0*)?*[zZ]?*)?

Please consider this change though it's small. This is affecting many prominent OData offering backends like Microsoft and SAP.

Thanks,
Punith
}}

> CLONE - EdmDateTime format validation while parsing
> ---------------------------------------------------
>
>                 Key: OLINGO-1173
>                 URL: https://issues.apache.org/jira/browse/OLINGO-1173
>             Project: Olingo
>          Issue Type: Question
>          Components: odata2-core
>    Affects Versions: V2 2.0.6
>            Reporter: Punith DG
>            Assignee: Christian Amend
>
> Hi Olingo Dev,
> I am using olingo(for OData2 ) as a client to access some OData providers' APIs .
> I am using below jars 
> olingo-odata2-core-2.0.6.jar
> olingo-odata2-api-2.0.6.jar
> Olingo fails to parse the EdmDateTime field when the OData provider sends it with a wrong data format 
> e.g.
> <d:CreatedOn m:type="Edm.DateTime">2016-03-22T08:36:24Z</d:CreatedOn> data for a Edm.DateTime field.
> Microsoft dynamics CRM sends all its EdmDateTime in this wrong format.
> Form the olingo code it looks like you force the data type to have the exact same format that of the primitive types supported by OData. As defined here http://www.odata.org/documentation/odata-version-2-0/overview/#AbstractTypeSystem
> So this way an EdmDateTime should be always of this type --> 2000-12-12T12:00
> while parsing this date we are getting below exception
>  Caused by: org.apache.olingo.odata2.api.edm.EdmSimpleTypeException: The literal '2016-04-04T21:53:44Z' is not formatted properly.
>       at org.apache.olingo.odata2.core.edm.EdmDateTime.parseLiteral(EdmDateTime.java:116)
>       at org.apache.olingo.odata2.core.edm.EdmDateTime.internalValueOfString(EdmDateTime.java:91)
>       at org.apache.olingo.odata2.core.edm.AbstractSimpleType.valueOfString(AbstractSimpleType.java:91)
>       at org.apache.olingo.odata2.core.ep.consumer.XmlPropertyConsumer.convert(XmlPropertyConsumer.java:206)
>       at org.apache.olingo.odata2.core.ep.consumer.XmlPropertyConsumer.readStartedElement(XmlPropertyConsumer.java:192)
>       at org.apache.olingo.odata2.core.ep.consumer.XmlEntryConsumer.readProperties(XmlEntryConsumer.java:591)
>       at org.apache.olingo.odata2.core.ep.consumer.XmlEntryConsumer.readContent(XmlEntryConsumer.java:544)
>       at org.apache.olingo.odata2.core.ep.consumer.XmlEntryConsumer.handleStartedTag(XmlEntryConsumer.java:137)
>       at org.apache.olingo.odata2.core.ep.consumer.XmlEntryConsumer.readEntry(XmlEntryConsumer.java:89)
> As a consumer/client this is stopping us from using a major part of the API specially query. 
> Question:
> 1) Is there any kind of configuration in olingo that allows olingo clients to avoid this validation ?
> 2) Is there any way I can override those classes to relax validation?
>      I do not see any way to override EdmDateTime class (package org.apache.olingo.odata2.core.edm)
>      As org.apache.olingo.odata2.core.edm.EdmDateTime.parseLiteral(String, EdmFacets, Calendar) being a static method. Looks like you don’t want anyone to override them.
> 3) Do you regard this as an issue or is it Working as design ? If it is working as designed, then is there a way to work around this,  
>    so that as a client we will still be able to parse wrong formatted data?
> 4) If there is no step taken yet and in case it is a well-known issue(?), is there any near future plan to address this issue ?
> Thanks,
> Rahul



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)