[
https://issues.apache.org/jira/browse/CALCITE-7146?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18016688#comment-18016688
]
Mihai Budiu commented on CALCITE-7146:
--------------------------------------
The strange thing is that there are two tests in SqlOperatorTest exactly for
this case written in 2023 by [~snuyanzin]:
{code:java}
MONTH_VARIANTS.forEach(s ->
f.checkScalar("timestampdiff(" + s + ", "
+ "time '12:42:25', date '2016-06-14')",
"-1502389", "INTEGER NOT NULL"));
MONTH_VARIANTS.forEach(s ->
f.checkScalar("timestampdiff(" + s + ", "
+ "date '2016-06-14', time '12:42:25')",
"1502389", "INTEGER NOT NULL"));
{code}
I wonder how these results were derived.
> TIMESTAMPDIFF accepts arguments with mismatched types
> -----------------------------------------------------
>
> Key: CALCITE-7146
> URL: https://issues.apache.org/jira/browse/CALCITE-7146
> Project: Calcite
> Issue Type: Bug
> Components: core
> Affects Versions: 1.40.0
> Reporter: Mihai Budiu
> Priority: Minor
>
> Calcite will typecheck this:
> {code:sql}
> SELECT TIMESTAMPDIFF(DAY, DATE '2020-01-01', TIME '10:00:00')
> {code}
> and reduce it to 36000000 - 18262, subtracting days from milliseconds.
> One solution would be to reject arithmetic between DATE and TIME. Another
> solution would be to treat this by casting both to TIMESTAMP. Of course, the
> semantics of casting a TIME to TIMESTAMP is also not clearly defined -
> currently Calcite seems to use Unix EPOCH for the DATE in such casts.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
