[
https://issues.apache.org/jira/browse/CALCITE-3597?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16995050#comment-16995050
]
Julian Hyde commented on CALCITE-3597:
--------------------------------------
I've thought some more about this:
* I agree that {{SqlFunctions.internalToTimestamp}} should be the inverse of
{{SqlFunctions.toLong}} (I think "inverse of" is clear than saying "not
asymmetric").
* Because of changes in timezones, the mapping between UTC and local time is
not 1:1. (Maybe Shanghai 1900 is an example of that.) For those values, it is
impossible for those functions to be inverses. People who use these functions
have to live with that.
* Those functions are not tested, or very well documented. They need to be.
* We need to be very clear that these functions are for one thing only:
converting arguments and results of UDFs. The vast majority of conversions of
TIMESTAMP in Calcite treat it as zoneless (therefore no timezone shift needs to
occur). Or, when going to and from JDBC, an explicit timezone is provided.
> 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: 0.5h
> 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)
