[
https://issues.apache.org/jira/browse/CALCITE-5269?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17607421#comment-17607421
]
Julian Hyde commented on CALCITE-5269:
--------------------------------------
{quote}
Would it be safe to treat a BQ DATETIME as a Calcite TIMESTAMP with no timezone
for the purposes of DATETIME constructors and the operand/return types for
function calls?
{quote}
In terms of representation, {{DATETIME}} and {{TIMESTAMP}} can both be
represented as 64 bit integers.
In terms of semantics, things might get a bit tricky. Suppose there is a
BigQuery function that takes a {{TIMESTAMP}} value and a time zone, and I pass
say 'America/Los Angeles' as the time zone. Since a BigQuery {{TIMESTAMP}} is
an instant, the time zone will mean "convert the instant to California local
time", which *subtracts* 8 hours (7 hours in summer).
But a Calcite {{TIMESTAMP}} is a local time, so the time zone would mean
"convert this California local time to an instant", which would *add* 8 hours
(7 hours in summer).
I think if you can get the tests in {{big-query.iq}} to pass that's a good
start, and we can see where to go from there.
> Implement BigQuery TIME_TRUNC and TIMESTAMP_TRUNC functions
> -----------------------------------------------------------
>
> Key: CALCITE-5269
> URL: https://issues.apache.org/jira/browse/CALCITE-5269
> Project: Calcite
> Issue Type: Sub-task
> Reporter: TJ Banghart
> Assignee: TJ Banghart
> Priority: Major
>
> Implement missing BigQuery functions for:
> * TIME_TRUNC
> * TIMESTAMP_TRUNC
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
