On 24/03/2014 10:02, Amend, Christian wrote:
Hi Francesco,
the changes you have made look fine to me. So you can go ahead and merge :-)
(As you might have guessed from the number of commit notification
e-mails) just done :-)
Regards.
-----Original Message-----
From: Francesco Chicchiriccò [mailto:ilgro...@apache.org]
Sent: Samstag, 22. März 2014 16:21
To: dev@olingo.incubator.apache.org
Subject: Re: Time primitive types for V4
On 22/03/2014 14:15, Francesco Chicchiriccò wrote:
Hi,
I have opened OLINGO-214 for this, and attached a patch there: please
take a look and let me know if it is fine, so that I will commit it.
FYI, I have also made some enhancements to V3 EdmDateTime - you can
take a look at the version at https://paste.apache.org/hRR3
As commented in OLINGO-214, I removed that patch that got quickly
obsolete: please take a look at mentioned classes in the olingo200
branch for reference.
Regards.
On 22/03/2014 12:00, Francesco Chicchiriccò wrote:
Hi all,
I am almost done with OLINGO-65 and all client code is now using
Olingo's EdmType hierarchy, including EdmPrimitiveType children.
I am currently experiencing some troubles because EdmTimeOfDay /
EdmDateTimeOffset are not working as I would expect.
In the OData 4.0 ABNF grammar you can find that
dateTimeOffsetValue = year "-" month "-" day "T" hour ":" minute [
":" second [ "." fractionalSeconds ] ] ( "Z" / sign hour ":" minute )
timeOfDayValue = hour ":" minute [ ":" second [ "." fractionalSeconds
] ]
fractionalSeconds = 1*12DIGIT
This barely refers to EdmTimeOfDay / EdmDateTimeOffset literals and
states that you can have up to 12 fractional seconds digits, right?
But EdmTimeOfDay [2] and EdmDateTimeOffset [3] are only able to deal
with 3 fractional seconds digit - mostly because both internally use
Calendar as concrete implementation, and its precision arrives to
milliseconds at most.
As part of OLINGO-65 I have developed EdmDateTime for V3 (which you
can find at [4] since I haven't pushed yet); as you can see, it works
differently: instead of relying upon regexp, it uses SimpleDateFormat
and supports both Calendar and java.sql.Timestamp - which allows up
to nanoseconds.
What do you think? Shall I try to extends [2] and [3] to make them
able to work with up to 12 fractional second digits, as EdmDateTime
is doing? Even leaving the regexp mechanism there, in fact, I would
need to use java.sql.Timestamp as internal representation.
Moreover, [5] states, about "Precision" facet, that
For a temporal property the value of this attribute specifies the
number of decimal places allowed in the seconds portion of the
property's value; it MUST be a non-negative integer between zero and
twelve. If no value is specified, the temporal property has a
precision of zero.
However, [3] do take the precision parameter into account (while [2]
does).
Shall we fix this as well?
Regards.
[1]
http://docs.oasis-open.org/odata/odata/v4.0/os/abnf/odata-abnf-construction-rules.txt
[2]
https://git-wip-us.apache.org/repos/asf?p=incubator-olingo-odata4.git;a=blob;f=lib/commons-core/src/main/java/org/apache/olingo/commons/core/edm/primitivetype/EdmTimeOfDay.java;
[3]
https://git-wip-us.apache.org/repos/asf?p=incubator-olingo-odata4.git;a=blob;f=lib/commons-core/src/main/java/org/apache/olingo/commons/core/edm/primitivetype/EdmDateTimeOffset.java;
[4] https://paste.apache.org/jilL
[5]
http://docs.oasis-open.org/odata/odata/v4.0/os/part3-csdl/odata-v4.0-os-part3-csdl.html#_Attribute_Precision_1
--
Francesco Chicchiriccò
Tirasa - Open Source Excellence
http://www.tirasa.net/
Involved at The Apache Software Foundation:
member, Syncope PMC chair, Cocoon PMC, Olingo PMC
http://people.apache.org/~ilgrosso/
