[
https://issues.jboss.org/browse/TEIID-2112?page=com.atlassian.jira.plugin...
]
RH Bugzilla Integration commented on TEIID-2112:
------------------------------------------------
jolee(a)redhat.com made a comment on [bug
851724|https://bugzilla.redhat.com/show_bug.cgi?id=851724]
+++ This bug was initially created as a clone of Bug #842433 +++
Description of problem:
Please reference the salesforce ticket
Version-Release number of selected component (if applicable):
How reproducible:
Steps to Reproduce:
1.
2.
3.
Actual results:
Expected results:
Additional info:
--- Additional comment from jira-update(a)redhat.com on 2012-07-23 21:42:20 EDT ---
Steven Hawkins <shawkins(a)redhat.com> updated the status of jira TEIID-2112 to
Resolved
--- Additional comment from jira-update(a)redhat.com on 2012-07-23 21:42:20 EDT ---
Steven Hawkins <shawkins(a)redhat.com> made a comment on jira TEIID-2112
Updated the xmltablenode conversion of Saxon CalendarValues.
--- Additional comment from jolee(a)redhat.com on 2012-07-24 10:03:44 EDT ---
Committed r4261 to
https://svn.jboss.org/repos/teiid/branches/7.4.x
--- Additional comment from jira-update(a)redhat.com on 2012-08-23 10:40:08 EDT ---
Marc Shirley <mshirley(a)redhat.com> made a comment on jira TEIID-2112
This fix appears to break pre-Gregorian dates from being interpreted correctly. Executing
the below query after patching results in a "java.lang.IllegalArgumentException:
WEEK_OF_YEAR" exception (tested in 7.4 and 7.7 versions).
select * from xmltable('/a' passing convert('<a
dt="2012-01-01T12:00:00" dtz="2012-01-01T12:00:00Z"
est="2012-01-01T12:00:00-05:00" bot="0001-01-01T00:00:00"
d="2012-08-16" t="12:00:00"/>', xml) columns unsigned timestamp
path '@dt', zuluSigned timestamp path '@dtz', estSigned timestamp path
'@est', beginningOfTime timestamp path '@bot', dateLocal date path
'@d', timeLocal time path '@t') as x
Further testing finds that this appears to be related to the Gregorian calendar cutover as
it appears to fail on converting any timestamps before the year 1583. By changing the
value of the attribute "bot" to "1583-01-01T00:00:00", the query
succeeds.
--- Additional comment from jira-update(a)redhat.com on 2012-08-23 10:40:47 EDT ---
Marc Shirley <mshirley(a)redhat.com> updated the status of jira TEIID-2112 to
Reopened
--- Additional comment from jira-update(a)redhat.com on 2012-08-23 10:49:20 EDT ---
Steven Hawkins <shawkins(a)redhat.com> updated the status of jira TEIID-2112 to
Resolved
--- Additional comment from jira-update(a)redhat.com on 2012-08-23 10:49:20 EDT ---
Steven Hawkins <shawkins(a)redhat.com> made a comment on jira TEIID-2112
Marking as resolved. There is a related, but more general issue that will be opened
separately.
--- Additional comment from jira-update(a)redhat.com on 2012-08-23 13:19:54 EDT ---
Steven Hawkins <shawkins(a)redhat.com> updated the status of jira TEIID-2112 to
Reopened
--- Additional comment from jira-update(a)redhat.com on 2012-08-23 13:19:54 EDT ---
Steven Hawkins <shawkins(a)redhat.com> made a comment on jira TEIID-2112
This is specific to xmltable even though the timestamp code is shared due to Saxon calling
cal.setGregorianChange(new Date(Long.MIN_VALUE));
--- Additional comment from jira-update(a)redhat.com on 2012-08-23 13:56:50 EDT ---
Steven Hawkins <shawkins(a)redhat.com> updated the status of jira TEIID-2112 to
Resolved
--- Additional comment from jira-update(a)redhat.com on 2012-08-23 13:56:50 EDT ---
Steven Hawkins <shawkins(a)redhat.com> made a comment on jira TEIID-2112
8.1 was just a partial resolution as pre-gregorian values would throw an exception.
consistent handling of local timezone on xsd:date, xsd:datetime, and
xsd:time values that have no timezone specified.
---------------------------------------------------------------------------------------------------------------------
Key: TEIID-2112
URL:
https://issues.jboss.org/browse/TEIID-2112
Project: Teiid
Issue Type: Bug
Components: Query Engine
Affects Versions: 7.1
Reporter: Johnathon Lee
Assignee: Steven Hawkins
Fix For: 7.4.4, 8.1, 8.2
The server is taking the incoming ts string and converting it to a Z value via the server
timezone (handled by STax). When the response document is delivered Saxon converts a
non-timezoned value into an assumed Z value - which is not consistent with the STax
handling. This is within the bounds of XML processing as the absence of timezone
information leaves the timezone interpretation up to the implementation - "timezone
of some unspecified locality as prescribed by the appropriate legal authority".
However, these two paths should be consistent,so a patch would set the local timezone on
xsd:date, xsd:datetime, and xsd:time values that have no timezone specified.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.jboss.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see:
http://www.atlassian.com/software/jira