[
https://issues.apache.org/jira/browse/IGNITE-17376?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17937363#comment-17937363
]
Konstantin Orlov edited comment on IGNITE-17376 at 3/21/25 10:41 AM:
---------------------------------------------------------------------
On the one hand, Sql standard defines timestamp literal as keyword
{{TIMESTAMP}} followed by timestamp string. The type of such literal is derived
based on whether time zone displacement is provided or not: if timestamp string
contains time zone displacement, then derived type is {{TIMESTAMP WITH TIME
ZONE}}, otherwise the type is {{TIMESTAMP}} (see {{SQL 2016 Foundation, 5.3
Literal, Syntax rules 27}}).
On the other, default parser doesn't allow to specify time zone displacement
neither for {{TIMESTAMP}} literal nor for {{TIMESTAMP WITH LOCAL TIME ZONE}}.
Both literal strings represents timestamp in the local to current session
timezone, therefore can be only converted to UTC with regard to time zone value
from session.
Also, the support for type {{TIMESTAMP WITH TIME ZONE}} has been added recently
to calcite, but since it's not directly assignable to {{TIMESTAMP WITH LOCAL
TIME ZONE}} in our type system, implicit cast is required.
Given that said, in order to support defaults for type {{TIMESTAMP WITH LOCAL
TIME ZONE}}, we have to support functional defaults.
was (Author: korlov):
On the one hand, Sql standard defines timestamp literal as keyword
{{TIMESTAMP}} followed by timestamp string. The type of such literal is derived
based on whether time zone displacement is provided or not: if timestamp string
contains time zone displacement, then derived type is {{TIMESTAMP WITH TIME
ZONE}}, otherwise the type is {{TIMESTAMP}} (see {{SQL 2016 Foundation, 5.3
Literal, Syntax rules 27}}).
On the other, default parser doesn't allow to specify time zone displacement
neither for {{TIMESTAMP}} literal to for {{TIMESTAMP WITH LOCAL TIME ZONE}}.
Both literal strings represents timestamp in the local to current session
timezone, therefore can be only converted to UTC with regard to time zone value
from session.
Also, the support for type {{TIMESTAMP WITH TIME ZONE}} has been added recently
to calcite, but since it's not directly assignable to {{TIMESTAMP WITH LOCAL
TIME ZONE}} in our type system, implicit cast is required.
Given that said, in order to support defaults for type {{TIMESTAMP WITH LOCAL
TIME ZONE}}, we have to support functional defaults.
> Sql. Investigate of support default value for TIMESTAMP WITH LOCAL TIME ZONE
> type
> ----------------------------------------------------------------------------------
>
> Key: IGNITE-17376
> URL: https://issues.apache.org/jira/browse/IGNITE-17376
> Project: Ignite
> Issue Type: Bug
> Components: sql
> Reporter: Konstantin Orlov
> Priority: Major
> Labels: ignite-3, tech-debt
>
> Currently default value is not supported for columns with type {{TIMESTAMP
> WITH LOCAL TIME ZONE}}, because behaviour is not clear:
> * if default value literal MUST contain time zone, then sql parser should be
> extended to provide ability to specify timestamp with time zone literal
> * if default value literal MAY NOT contain time zone, then some research is
> needed. Consider the following case:
> {code:java}
> CREATE TABLE t (id INT PRIMARY KEY, val TIMESTAMP WITH LOCAL TIME ZONE
> DEFAULT TIMESTAMP '2021-01-01 01:01:01')
> {code}
> Which timezone should be chosen for converting this literal to UTC: timezone
> of the server or timezone of the client who create this table? Should the
> inserted values be the same in case the user inserts values explicitly or
> implicitly (though DEFAULT) like that:
> {code:java}
> INSERT INTO t (id) VALUES (0);
> VS
> INSERT INTO t (id, val) VALUES (0, DEFAULT);
> VS
> INSERT INTO t (id, val) VALUES (0, TIMESTAMP '2021-01-01 01:01:01');
> {code}
> Let's provide some research on this topic and chose the proper way to address
> the issue.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
