[jira] [Commented] (CALCITE-2710) Some SqlFunctions use LOCAL_TZ constant instead of using timeZone()
[ https://issues.apache.org/jira/browse/CALCITE-2710?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16699679#comment-16699679 ] Andrew Pilloud commented on CALCITE-2710: - I think this is just a plumbing issue, I plan to work on it shortly. > Some SqlFunctions use LOCAL_TZ constant instead of using timeZone() > --- > > Key: CALCITE-2710 > URL: https://issues.apache.org/jira/browse/CALCITE-2710 > Project: Calcite > Issue Type: Bug > Components: core >Reporter: Andrew Pilloud >Assignee: Julian Hyde >Priority: Major > > There are several methods in SqlFunctions which use a LOCAL_TZ constant to > determine the file. This constant is the default system time zone, but the > local time zone can be modified on the connection. This results in incorrect > behavior if the system time zone and connection time zone differ, for example > adding an offset and removing a different offset. These functions should be > calling the timeZone method which fetches the local timezone from the > DataContext. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (CALCITE-2710) Some SqlFunctions use LOCAL_TZ constant instead of using timeZone()
[ https://issues.apache.org/jira/browse/CALCITE-2710?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16699778#comment-16699778 ] Julian Hyde commented on CALCITE-2710: -- Before we dive down this rat hole, are we agreed that Calcite's SQL functions work on zoneless TIME and TIMESTAMP values? The LOCAL_TZ is only intended for arguments to and values returned from UDFs. These are values that need to be converted from local time (of the JVM) to zoneless. Nothing to do with the connection's time zone. > Some SqlFunctions use LOCAL_TZ constant instead of using timeZone() > --- > > Key: CALCITE-2710 > URL: https://issues.apache.org/jira/browse/CALCITE-2710 > Project: Calcite > Issue Type: Bug > Components: core >Reporter: Andrew Pilloud >Assignee: Julian Hyde >Priority: Major > > There are several methods in SqlFunctions which use a LOCAL_TZ constant to > determine the file. This constant is the default system time zone, but the > local time zone can be modified on the connection. This results in incorrect > behavior if the system time zone and connection time zone differ, for example > adding an offset and removing a different offset. These functions should be > calling the timeZone method which fetches the local timezone from the > DataContext. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (CALCITE-2710) Some SqlFunctions use LOCAL_TZ constant instead of using timeZone()
[ https://issues.apache.org/jira/browse/CALCITE-2710?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16701121#comment-16701121 ] Andrew Pilloud commented on CALCITE-2710: - Yes, I see that now. (Passing UDFs time in local timezone values seems a little strange, but if it converts back it should work.) So what it looks like I'm seeing is that ReflectiveCallNotNullImplementor converts from internal values to these types but doesn't convert back to the internal types. I have a custom 'castOutput' function that converts Calcite types back to Beam rows, if I send the java.sql types through the appropriate conversion back the issues I am seeing goes away. So the bug is on my end, not Calcite. > Some SqlFunctions use LOCAL_TZ constant instead of using timeZone() > --- > > Key: CALCITE-2710 > URL: https://issues.apache.org/jira/browse/CALCITE-2710 > Project: Calcite > Issue Type: Bug > Components: core >Reporter: Andrew Pilloud >Assignee: Julian Hyde >Priority: Major > > There are several methods in SqlFunctions which use a LOCAL_TZ constant to > determine the file. This constant is the default system time zone, but the > local time zone can be modified on the connection. This results in incorrect > behavior if the system time zone and connection time zone differ, for example > adding an offset and removing a different offset. These functions should be > calling the timeZone method which fetches the local timezone from the > DataContext. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (CALCITE-2710) Some SqlFunctions use LOCAL_TZ constant instead of using timeZone()
[ https://issues.apache.org/jira/browse/CALCITE-2710?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16701232#comment-16701232 ] Julian Hyde commented on CALCITE-2710: -- Yeah, it's very confusing. Sorry about that. The root cause is that Java's date-time types are instants (i.e. relative to UTC epoch) whereas SQL's date-time types are zoneless. Going back and forth is always complicated. > Some SqlFunctions use LOCAL_TZ constant instead of using timeZone() > --- > > Key: CALCITE-2710 > URL: https://issues.apache.org/jira/browse/CALCITE-2710 > Project: Calcite > Issue Type: Bug > Components: core >Reporter: Andrew Pilloud >Assignee: Julian Hyde >Priority: Major > > There are several methods in SqlFunctions which use a LOCAL_TZ constant to > determine the file. This constant is the default system time zone, but the > local time zone can be modified on the connection. This results in incorrect > behavior if the system time zone and connection time zone differ, for example > adding an offset and removing a different offset. These functions should be > calling the timeZone method which fetches the local timezone from the > DataContext. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
