You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@calcite.apache.org by "Evgeny Stanilovsky (Jira)" <ji...@apache.org> on 2023/05/02 09:30:00 UTC

[jira] (CALCITE-5678) Calcite should reject date literals not satisfying Gregorian calendar, per SQL standard

    [ https://issues.apache.org/jira/browse/CALCITE-5678 ]


    Evgeny Stanilovsky deleted comment on CALCITE-5678:
    ---------------------------------------------

was (Author: zstan):
# from LocalDateTime  java doc we can found: 
{noformat}
The ISO-8601 calendar system is the modern civil calendar system used today in most of the world. It is equivalent to the proleptic Gregorian calendar system, in which today's rules for leap years are applied for all time. For most applications written today, the ISO-8601 rules are entirely suitable. However, any application that makes use of historical dates, and requires them to be accurate will find the ISO-8601 approach unsuitable.{noformat}
 

 #  As i can see from PR above, we already have a mix of gregorian\julian transformations [link title|https://github.com/apache/calcite/pull/2995/files#diff-23301236e7a9c0e772620a2093cce6a979d7703c511f2417973fae0b26ee62b3R2314] so we can fully replace julian calendar logic in future

 # I check and DATE '1752-09-09' is correctly parsed (no errors raised) by other known databases.

> Calcite should reject date literals not satisfying Gregorian calendar, per SQL standard
> ---------------------------------------------------------------------------------------
>
>                 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)