[ https://issues.apache.org/jira/browse/CALCITE-3597?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16994329#comment-16994329 ]
Julian Hyde edited comment on CALCITE-3597 at 12/12/19 7:39 AM: ---------------------------------------------------------------- Can you give an example of a SQL query where we currently do the wrong thing? I am skeptical that there is a problem here. Methods in SqlFunctions should only be called internally by Calcite, and afaik Calcite’s SQL functions all work fine. Also, did you see this: http://mail-archives.apache.org/mod_mbox/calcite-dev/201907.mbox/%3c1fcf4568-09db-49e3-8f86-c284e744b...@gmail.com%3E ? was (Author: julianhyde): Can you give an example of a SQL query where we currently do the wrong thing? I am skeptical that there is a problem here. Methods in SqlFunctions should only be called internally by Calcite, and afaik Calcite’s SQL functions all work fine. > The conversion between java.sql.Timestamp and long is not asymmetric > -------------------------------------------------------------------- > > Key: CALCITE-3597 > URL: https://issues.apache.org/jira/browse/CALCITE-3597 > Project: Calcite > Issue Type: Bug > Components: core > Affects Versions: 1.21.0 > Reporter: Zhenghua Gao > Priority: Major > Labels: pull-request-available > Time Spent: 10m > Remaining Estimate: 0h > > In Calcite, we use SqlFunctions.toLong(Timestamp) and > SqlFunctions.internalToTimestamp(long) to convert java.sql.Timestmap to > internal long and vice versa. The main logical inside is +/- local time zone > offset. > But in the comments of TimeZone.getOffset(long date), the parameter > represents in milliseconds since January 1, 1970 00:00:00 GMT. It means that > there will one conversion above doesn't satisfy this hypothesis. > > This causes many surprise to users: > (1) some Daylight Saving Time changes: > > {code:java} > @Test public void testDayLightingSaving() { > TimeZone tz = TimeZone.getDefault(); > TimeZone.setDefault(TimeZone.getTimeZone("America/Los_Angeles")); > java.sql.Timestamp dst2018Begin = java.sql.Timestamp.valueOf("2018-03-11 > 03:00:00"); > assertThat(dst2018Begin, is(internalToTimestamp(toLong(dst2018Begin)))); > TimeZone.setDefault(tz); > }{code} > fails with: > {code:java} > java.lang.AssertionError: > Expected: is <2018-03-11 04:00:00.0> > but: was <2018-03-11 03:00:00.0> > Expected :is <2018-03-11 04:00:00.0> > Actual :<2018-03-11 03:00:00.0>{code} > > (2) "1900-01-01 00:00:00" Changes in some TimeZone > {code:java} > @Test public void test() { > TimeZone tz = TimeZone.getDefault(); > TimeZone.setDefault(TimeZone.getTimeZone("Asia/Shanghai")); > java.sql.Timestamp ts = java.sql.Timestamp.valueOf("1900-01-01 00:00:00"); > assertThat(ts, is(internalToTimestamp(toLong(ts)))); > TimeZone.setDefault(tz); > }{code} > fails with > {code:java} > java.lang.AssertionError: > Expected: is <1899-12-31 23:54:17.0> > but: was <1900-01-01 00:00:00.0> > Expected :is <1899-12-31 23:54:17.0> > Actual :<1900-01-01 00:00:00.0> > {code} > > > -- This message was sent by Atlassian Jira (v8.3.4#803005)