[
https://issues.jboss.org/browse/TEIID-3938?page=com.atlassian.jira.plugin...
]
Steven Hawkins commented on TEIID-3938:
---------------------------------------
Is there a reason for the system property with EdmDateTimeOffset and not the other types?
You could also simplify things in EdmDateTimeOffset:
{code}
Calendar dateTimeValue = null;
// normalize to GMT for output
if (Boolean.getBoolean("normalizeEdmDateTimeOffsetToGMT")) {
dateTimeValue = createDateTimeInGMT(value);
} else {
dateTimeValue = createDateTime(value);
}
{code}
And move createDateInGMT method to EdmDateTimeOffset as createDateTimeInGMT.
You can also avoid creating the additional Calendar in createDateTimeInGMT in the Calendar
case, but that's a very minor concern.
EdmDate and EdmTimeOfDay output in local timezone
-------------------------------------------------
Key: TEIID-3938
URL:
https://issues.jboss.org/browse/TEIID-3938
Project: Teiid
Issue Type: Bug
Components: Misc. Connectors
Reporter: Steven Hawkins
Assignee: Ramesh Reddy
Fix For: 8.12.5
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. So when Teiid is
on a server not in GMT date and time value sent via the odata4 translator will likely be
wrong.
Ramesh:
I have posted a question to the Olingo development group here
http://markmail.org/search/list:org.apache.olingo.dev#query:list%3Aorg.ap...
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)