[jira] [Created] (CALCITE-4295) The minMin function of CompositeOperandTypeChecker should returns the minimum of lower bound of all SqlOperandCountRange

Zhenghua Gao created CALCITE-4295: - Summary: The minMin function of CompositeOperandTypeChecker should returns the minimum of lower bound of all SqlOperandCountRange Key: CALCITE-4295 URL: https

[jira] [Created] (CALCITE-3881) SqlFunctions#addMonths yields incorrect results in some corner case

Zhenghua Gao created CALCITE-3881: - Summary: SqlFunctions#addMonths yields incorrect results in some corner case Key: CALCITE-3881 URL: https://issues.apache.org/jira/browse/CALCITE-3881 Project

Re: [DISCUSS] Restart the work of introducing TIME/TIMESTAMP WITH TIME ZONE types to Calcite

(as you mentioned above) 2) [long/int + TimeZone] is simple and clear for the semantic of TIME/TIMESTAMP WITH TIME ZONE *Best Regards,* *Zhenghua Gao* On Sat, Dec 21, 2019 at 3:30 AM Rui Wang wrote: > In general, I incline to a solution of saving timestamp with time zone by > [long + a

Re: [DISCUSS] Restart the work of introducing TIME/TIMESTAMP WITH TIME ZONE types to Calcite

really find the first semantic exists in > Calcite, maybe I have missed something). > > [1]: > > https://docs.google.com/document/d/1gNRww9mZJcHvUDCXklzjFEQGpefsuR_akCDfWsdE35Q/edit# > > -Rui > > > On Thu, Dec 19, 2019 at 6:27 PM Zhenghua Gao wrote: > > >

[jira] [Created] (CALCITE-3615) Improve JDBC driver to support java.time classes

Zhenghua Gao created CALCITE-3615: - Summary: Improve JDBC driver to support java.time classes Key: CALCITE-3615 URL: https://issues.apache.org/jira/browse/CALCITE-3615 Project: Calcite Issue

[jira] [Created] (CALCITE-3614) Support TIME/TIMESTAMP WITH TIME ZONE literals

Zhenghua Gao created CALCITE-3614: - Summary: Support TIME/TIMESTAMP WITH TIME ZONE literals Key: CALCITE-3614 URL: https://issues.apache.org/jira/browse/CALCITE-3614 Project: Calcite Issue

[jira] [Created] (CALCITE-3613) Support TIME/TIMESTAMP WITH TIME ZONE in Calcite SQL parser and builtin functions

Zhenghua Gao created CALCITE-3613: - Summary: Support TIME/TIMESTAMP WITH TIME ZONE in Calcite SQL parser and builtin functions Key: CALCITE-3613 URL: https://issues.apache.org/jira/browse/CALCITE-3613

[jira] [Created] (CALCITE-3612) Add TIME/TIMESTAMP WITH TIME ZONE in optimizer

Zhenghua Gao created CALCITE-3612: - Summary: Add TIME/TIMESTAMP WITH TIME ZONE in optimizer Key: CALCITE-3612 URL: https://issues.apache.org/jira/browse/CALCITE-3612 Project: Calcite Issue

Re: [DISCUSS] Restart the work of introducing TIME/TIMESTAMP WITH TIME ZONE types to Calcite

Thanks for your comments! I have opened an umbrella issue[1] to track this. [1] https://issues.apache.org/jira/browse/CALCITE-3611 *Best Regards,* *Zhenghua Gao* On Fri, Dec 20, 2019 at 4:05 AM Julian Hyde wrote: > It would be great to have a timestamp type with (timeZone, number) d

[jira] [Created] (CALCITE-3611) Introduce TIME/TIMESTAMP WITH TIME ZONE types

Zhenghua Gao created CALCITE-3611: - Summary: Introduce TIME/TIMESTAMP WITH TIME ZONE types Key: CALCITE-3611 URL: https://issues.apache.org/jira/browse/CALCITE-3611 Project: Calcite Issue

Re: [DISCUSS] Restart the work of introducing TIME/TIMESTAMP WITH TIME ZONE types to Calcite

You are right. PostgreSQL's TIMESTAMP WITH TIME ZONE has "Instant" semantics. That's the reason that CALCITE-1947 change the type as "TIMESTAMP WITH LOCAL TIME ZONE" *Best Regards,* *Zhenghua Gao* On Thu, Dec 19, 2019 at 4:17 PM Vladimir Sitnikov < sitnikov.vl

[DISCUSS] Restart the work of introducing TIME/TIMESTAMP WITH TIME ZONE types to Calcite

browse/CALCITE-208 [4] https://issues.apache.org/jira/browse/CALCITE-1784 *Best Regards,* *Zhenghua Gao*

[jira] [Created] (CALCITE-3597) The conversion between java.sql.Timestamp and long is not asymmetric

Zhenghua Gao created CALCITE-3597: - Summary: The conversion between java.sql.Timestamp and long is not asymmetric Key: CALCITE-3597 URL: https://issues.apache.org/jira/browse/CALCITE-3597 Project

[jira] [Created] (CALCITE-3529) TIMESTAMPDIFF function may overflow when handle unit of MICROSECOND/NANOSECOND

Zhenghua Gao created CALCITE-3529: - Summary: TIMESTAMPDIFF function may overflow when handle unit of MICROSECOND/NANOSECOND Key: CALCITE-3529 URL: https://issues.apache.org/jira/browse/CALCITE-3529

[jira] [Created] (CALCITE-3528) TIMESTAMPADD/TIMESTAMPDIFF can't handle unit of MILLISECOND

Zhenghua Gao created CALCITE-3528: - Summary: TIMESTAMPADD/TIMESTAMPDIFF can't handle unit of MILLISECOND Key: CALCITE-3528 URL: https://issues.apache.org/jira/browse/CALCITE-3528 Project: Calcite

[jira] [Created] (CALCITE-3497) Calcite TimestampString should provide getNanosInSecond interface

Zhenghua Gao created CALCITE-3497: - Summary: Calcite TimestampString should provide getNanosInSecond interface Key: CALCITE-3497 URL: https://issues.apache.org/jira/browse/CALCITE-3497 Project

[jira] [Created] (CALCITE-3199) DateTimeUtils.unixDateCeil returns the same value as unixDateFloor does

Zhenghua Gao created CALCITE-3199: - Summary: DateTimeUtils.unixDateCeil returns the same value as unixDateFloor does Key: CALCITE-3199 URL: https://issues.apache.org/jira/browse/CALCITE-3199 Project

[jira] [Created] (CALCITE-3151) RexCall's Monotonicity is not considered in determining a Calc's collation

Zhenghua Gao created CALCITE-3151: - Summary: RexCall's Monotonicity is not considered in determining a Calc's collation Key: CALCITE-3151 URL: https://issues.apache.org/jira/browse/CALCITE-3151

[jira] [Created] (CALCITE-1558) Wrong field mapping of top level aggregate for cases when groupKey is used in aggregate function

Zhenghua Gao created CALCITE-1558: - Summary: Wrong field mapping of top level aggregate for cases when groupKey is used in aggregate function Key: CALCITE-1558 URL: https://issues.apache.org/jira/browse/CALCITE