Zhenghua Gao created FLINK-15213: ------------------------------------ Summary: The conversion between java.sql.Timestamp and long is not asymmetric Key: FLINK-15213 URL: https://issues.apache.org/jira/browse/FLINK-15213 Project: Flink Issue Type: Bug Reporter: Zhenghua Gao
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)