[
https://issues.apache.org/jira/browse/CALCITE-3597?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16994396#comment-16994396
]
Zhenghua Gao edited comment on CALCITE-3597 at 12/12/19 8:52 AM:
-----------------------------------------------------------------
Add an error case in Asia/Shanghai:
Add a UDX in Smalls.AllTypesFunction:
{code:java}
public static Timestamp timestampFun2(Timestamp timestamp) {
return timestamp;
}{code}
Add a test in UdfTest.testDate
{code:java}
with.query("values \"adhoc\".\"timestampFun2\"(TIMESTAMP '1900-01-01
00:00:00')")
.returnsValue("1900-01-01 00:00:00");{code}
fail message is:
{code:java}
java.lang.AssertionError:
Expected: is "1900-01-01 00:00:00"
but: was "1899-12-31 23:54:17"
Expected :1900-01-01 00:00:00
Actual :1899-12-31 23:54:17{code}
was (Author: docete):
Add an error case:
Add a UDX in Smalls.AllTypesFunction:
{code:java}
public static Timestamp timestampFun2(Timestamp timestamp) {
return timestamp;
}{code}
Add a test in UdfTest.testDate
{code:java}
with.query("values \"adhoc\".\"timestampFun2\"(TIMESTAMP '1900-01-01
00:00:00')")
.returnsValue("1900-01-01 00:00:00");{code}
fail message is:
{code:java}
java.lang.AssertionError:
Expected: is "1900-01-01 00:00:00"
but: was "1899-12-31 23:54:17"
Expected :1900-01-01 00:00:00
Actual :1899-12-31 23:54:17{code}
> 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)
