[
https://issues.apache.org/jira/browse/OLINGO-864?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15137815#comment-15137815
]
Ramesh Reddy commented on OLINGO-864:
-------------------------------------
Great! let me take another wack at it in removing the System property with a
configuration in the OData. I will provide another patch.
>>If no timezone is set the library should continue to assume GMT in my opinion.
IMO, we leave it at default JVM timezone, we will have less confusion
explaining this to the service developer as to why we choose different
timezone, worse, service developer ignoring this will result in the wrong data
(which was case with my service ;))
> 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)
