[
https://issues.apache.org/jira/browse/OLINGO-864?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15144607#comment-15144607
]
Christian Amend commented on OLINGO-864:
----------------------------------------
[~rareddy] this seems consistent to me. This way we always use the same
timezone for both serialization and deserialization as long as the library is
on only one system.
Codewise I couldn`t get into details but at a first glance it looks good. I am
OK with a merge.
> 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)