[
https://issues.apache.org/jira/browse/OLINGO-864?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15136955#comment-15136955
]
Christian Amend edited comment on OLINGO-864 at 2/8/16 1:49 PM:
----------------------------------------------------------------
[~rareddy] you make a very good point that I did not see. I was so focused on
the timestamp class that I missed the Time and Date classes completely. So I
think we can agree that there needs to be some way of setting the timezone.
Now to do this I would prefer a setter or getter either globally at the OData
object which is used to create the de-/serializer or at the de-/serializer
classes themself. The ODataSerializer already has a SerializerOptions class in
the signature yet the deserializer does not have such an option in the
signature. So we might have to provide a second method in the deserializer with
Options in the signature to allow for this use case. Or we add a setter at the
deserializer directly like deserializer.setTimeZone(). This however would be
inconsistent with the similar serializer API.
We also need to overload the valueOfString and valueToString methods for the
EdmPrimitiveType to include a timezone either as a String or TimeZone object to
get this parameter into the EdmPrimitiveType instance.
If no timezone is set the library should continue to assume GMT in my opinion.
What do you prefer?
was (Author: chrisam):
@rareddy you make a very good point that I did not see. I was so focused on the
timestamp class that I missed the Time and Date classes completely. So I think
we can agree that there needs to be some way of setting the timezone.
Now to do this I would prefer a setter or getter either globally at the OData
object which is used to create the de-/serializer or at the de-/serializer
classes themself. The ODataSerializer already has a SerializerOptions class in
the signature yet the deserializer does not have such an option in the
signature. So we might have to provide a second method in the deserializer with
Options in the signature to allow for this use case. Or we add a setter at the
deserializer directly like deserializer.setTimeZone(). This however would be
inconsistent with the similar serializer API.
We also need to overload the valueOfString and valueToString methods for the
EdmPrimitiveType to include a timezone either as a String or TimeZone object to
get this parameter into the EdmPrimitiveType instance.
If no timezone is set the library should continue to assume GMT in my opinion.
What do you prefer?
> EdmDate and EdmTimeOfDay output in local timezone
> -------------------------------------------------
>
> Key: OLINGO-864
> URL: https://issues.apache.org/jira/browse/OLINGO-864
> Project: Olingo
> Issue Type: Bug
> Components: odata4-commons
> Affects Versions: (Java) V4 4.0.0-beta-01
> Reporter: Ramesh Reddy
> Assignee: Ramesh Reddy
> Priority: Critical
> Fix For: (Java) V4 4.2.0
>
>
> EdmDate and EdmTimeOfDay both assume GMT for incoming string values - however
> when the convert from Java objects to string they use the local/default
> Calendar.
> OData TC says parsing Date or Time should be exactly same in every time zone.
> This highlights the issue with EdmDate:
> TimeZone.setDefault(TimeZone.getTimeZone("GMT-1"));
> java.sql.Timestamp date = EdmDate.getInstance().valueOfString("2000-01-01",
> true, 4000, 0, 0, true, java.sql.Timestamp.class);
> assertEquals("1999-12-31 23:00:00.0", date.toString());
> String val = EdmDate.getInstance().valueToString(date, true, 4000, 0, 0,
> true);
> assertEquals("2000-01-01", date.toString());
> The last line fails because the date will be "1999-12-31" instead.
> Linked issue at https://issues.jboss.org/browse/TEIID-3938
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
