[
https://issues.apache.org/jira/browse/CALCITE-5919?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17757156#comment-17757156
]
Julian Hyde edited comment on CALCITE-5919 at 8/21/23 11:53 PM:
----------------------------------------------------------------
The default implementation of the SQL {{TIME}} data type should remain {{int}}
(and {{java.lang.Integer}} for nullable values).
Based on some criteria - say, a {{TIME}} data type that requires more than
about 31 bits of precision (9 decimal digits) - then we could switch to another
implementation. I'm fine for that alternative implementation to use
{{java.math.BigDecimal}}.
was (Author: julianhyde):
The default implementation of `TIME` should remain `int` (and
`java.lang.Integer`).
Based on some criteria - say, a `TIME` data type that requires more than about
31 bits of precision (9 decimal digits) - then we could switch to another
implementation. I'm fine for that alternative implementation to use
`BigDecimal`.
> Compile-time implementation of EXTRACT ignores sub-millisecond values
> ---------------------------------------------------------------------
>
> Key: CALCITE-5919
> URL: https://issues.apache.org/jira/browse/CALCITE-5919
> Project: Calcite
> Issue Type: Bug
> Components: core
> Affects Versions: 1.35.0
> Reporter: Mihai Budiu
> Priority: Minor
>
> When enabling the optimization rule PROJECT_REDUCE_EXPRESSIONS the
> compile-time evaluation of an expression like EXTRACT(MICROSECONDS FROM TIME
> '13:30:25.575401') will produce a result up to milliseconds only,
> irrespective of the type system provided. (This query will evaluate to
> 25575000 instead of 25575401).
> The bug is in RexImpTable.ExtractImplementor, here:
> {code:java}
> case MILLISECOND:
> case MICROSECOND:
> case NANOSECOND:
> if (sqlTypeName == SqlTypeName.DATE) {
> return Expressions.constant(0L);
> }
> operand = mod(operand, TimeUnit.MINUTE.multiplier.longValue(),
> !isIntervalType); // << BUG
> return Expressions.multiply(
> operand, Expressions.constant((long) (1 /
> unit.multiplier.doubleValue())));
> {code}
> The mod operation uses a multiplier for MINUTE that is expressed in
> milliseconds, so it always truncates away values below milliseconds. The
> multiplier seems to assume that the type system precision for TIME is set to
> 3, which is the default value, but may be overridden.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
