[
https://issues.apache.org/jira/browse/CALCITE-5678?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17717291#comment-17717291
]
Evgeny Stanilovsky edited comment on CALCITE-5678 at 4/27/23 5:32 PM:
----------------------------------------------------------------------
Sql 99 standard defines :
{noformat}
The <primary datetime field>s other than SECOND contain non-negative integer
values, con-
strained by the natural rules for dates using the _Gregorian_ calendar. SECOND,
however, can be
defined to have a <time fractional seconds precision> that indicates the number
of decimal digits
maintained following the decimal point in the seconds value, a _non-negative_
exact numeric value.
{noformat}
but it still possible in calcite:
{noformat}
insert into t values (1, '2013-20-14 00:00:00.-1');
insert into t values (1, '2023-02-35 01:00:00.0');{noformat}
Of course, this seems a broken change, thus i suggest a fix with minimal harm
of code.
I see that it`s possible to get rid of julian conversations at all, but as for
me - it`s too huge change and out of box = java native validator is enough
change for further steps. Also _TIMESTAMP WITH LOCAL TIME ZONE_ is implemented
through _SqlFunctions.toTimestampWithLocalTimeZone_ and there are still
erroneous behavior different from pure TIMESTAMP and seems this require
additional different issue.
was (Author: zstan):
Sql 99 standard defines :
{noformat}
The <primary datetime field>s other than SECOND contain non-negative integer
values, con-
strained by the natural rules for dates using the _Gregorian_ calendar. SECOND,
however, can be
defined to have a <time fractional seconds precision> that indicates the number
of decimal digits
maintained following the decimal point in the seconds value, a _non-negative_
exact numeric value.
{noformat}
but it still possible in calcite:
{noformat}
insert into t values (1, '2013-20-14 00:00:00.-1');
insert into t values (1, '2023-02-35 01:00:00.0');{noformat}
Of course, this seems a broken change, thus i suggest a fix with minimal harm
of code.
I see that it`s possible to get rid of julian conversations at all, but as for
me - it`s too huge change and out of box = java native validator is enough
change for further steps. Also _TIMESTAMP WITH LOCAL TIME ZONE_ is implemented
through _SqlFunctions.toTimestampWithLocalTimeZone_ and there are still
erroneous behavior different from pure TIMESTAMP and seems this need additional
different issue.
> Reject date literals not satisfying Gregorian calendar and sql standard rules.
> ------------------------------------------------------------------------------
>
> Key: CALCITE-5678
> URL: https://issues.apache.org/jira/browse/CALCITE-5678
> Project: Calcite
> Issue Type: Improvement
> Components: avatica
> Affects Versions: 1.34.0
> Reporter: Evgeny Stanilovsky
> Assignee: Evgeny Stanilovsky
> Priority: Major
> Labels: patch-available
>
> RexToLixTranslator now process datetime input\output string representation
> through transformation between gregorian and julian [1] calendars , thus no
> exception is raised if incorrect string is passed, just smart transformation
> instead.
> [1] org.apache.calcite.avatica.util.DateTimeUtils#timestampStringToUnixDate
> {noformat}
> create table t (i int not null, j timestamp);
> insert into t values (1, '2013-20-14 00:00:00');
> select * from t;
> > +---+---------------------+
> > | I | J |
> > +---+---------------------+
> > | 1 | 2014-08-16 00:00:00 |
> > +---+---------------------+{noformat}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
