You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@calcite.apache.org by "Julian Hyde (Jira)" <ji...@apache.org> on 2023/04/28 23:55:00 UTC
[jira] [Commented] (CALCITE-5678) Reject date literals not satisfying Gregorian calendar and sql standard rules.
[ https://issues.apache.org/jira/browse/CALCITE-5678?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17717847#comment-17717847 ]
Julian Hyde commented on CALCITE-5678:
--------------------------------------
Do you consider {{DATE '1752-09-09'}} to be a valid Gregorian date? (I don't have an opinion.) Because of the Gregorian shift:
{noformat}
$ cal 9 1752
September 1752
Su Mo Tu We Th Fr Sa
1 2 14 15 16
17 18 19 20 21 22 23
24 25 26 27 28 29 30
{noformat}
See CALCITE-5414 for discussion about (proleptic) Gregorian calendar.
> 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)