[
https://issues.apache.org/jira/browse/OLINGO-864?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15132487#comment-15132487
]
Ramesh Reddy commented on OLINGO-864:
-------------------------------------
[~chrisam] The basic premise of the issue is Edm.Date and Edm.TimeOfDay assume
"GMT" both while parsing, and producing the result, and this patch fixes that
assumption by moving from "GMT" to default Timezone of the JVM.
Edm.DateTimeOffset is not affected at all with this change as it already has
the TZ info in it.
Olingo framework's hard coded of usage of "GMT" as Timezone is *choice* that
needs to be placed with service developer, not to be forced upon. With the
current state, in order to get correct results, service developer MUST change
their java.sql.Time, java.sql.Date objects into GMT before they can send it to
Olingo code. Please note "valueToString" and "valueFromString" two disjoint
methods, there is no guarantee the same object created from "valueFromString"
is used in "valueToString".
Now, about your comments, Timestamp based code is same as before, it can not be
used as reference as it's internal state is always from epoch, where as Date
and Time are not, when you set specific fields those does matter during the
conversion, as they created in JVM's default timezone. Typically no developer
changes the Timezone of the JVM, and always work with local timezone, then we
get to above code in question we will get unpredictable results. A good example
is, I read Date and Time fields from my relational database using a JDBC
driver, they may be in database in GMT, however they are converted to my local
time zone either by database or JDBC driver, which I am in-turn sending to
Olingo. When I see the results the Date and Time values are skewed without this
patch. So, it is not just "Timestamp.toString" method issue, it is handling of
java.sql.Time and java.sql.Date objects also.
As per the System.getProperty, I am open for other suggestions, do not care
how one sets the property, either through system property or through some
configuration. In real service development, a developer never needs to set this
flag, unless they want *predictable* timezone values like in unit tests.
> 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)
