[ 
https://issues.apache.org/jira/browse/IGNITE-23772?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18050836#comment-18050836
 ] 

Vladimir Steshin commented on IGNITE-23772:
-------------------------------------------

*Calcite* does:
{code:java}
DateStringLiteral -> RexLiteral#getValueAs(Integer) -> 
DateString#getDaysSinceEpoch() -> DateTimeUtils#ymdToUnixDate(year, month, day) 
-> `return ymdToJulian(year, month, day) - EPOCH_JULIAN`{code}
{code:java}
Result#getDate() -> return DateTimeUtils#unixDateToSqlDate(v.intValue(), 
calendar);
{code}
{code:java}
LocalDate localDate = LocalDate.ofEpochDay(-141441);
java.sql.Date sqlDate = java.sql.Date.valueOf(localDate); {code}
 

*We* do:
{code:java}
DateStringLiteral -> RexLiteral#getValueAs(Integer) -> 
DateString#getDaysSinceEpoch() -> DateTimeUtils#ymdToUnixDate(year, month, day) 
-> `ymdToJulian(year, month, day) - EPOCH_JULIAN`{code}
{code:java}
TypeUtils#fromInternal() -> `return new java.sql.Date(fromLocalTs(ctx, -141441 
* DateTimeUtils.MILLIS_PER_DAY));`
{code}
 

Also we have `DateValueUtils` with another dates convertation. Probably, we 
should revise our `date-to-int/long` convertation and use the new java dates 
system and/or Calcite's convertation. And keep it in a single place (without 
`{_}DateValueUtils`{_})

> Calcite. Incorrect processing of old date literals.
> ---------------------------------------------------
>
>                 Key: IGNITE-23772
>                 URL: https://issues.apache.org/jira/browse/IGNITE-23772
>             Project: Ignite
>          Issue Type: Bug
>    Affects Versions: 2.14
>            Reporter: Vladimir Steshin
>            Assignee: Vladimir Steshin
>            Priority: Minor
>              Labels: calcite, ignite-2, ise
>
> Consider:
> *1)* {code:java}
> assertQuery("SELECT DATE '1582-10-05' + INTERVAL 1 
> DAYS").returns(Date.valueOf("1582-10-06")).check();
> ---
> assertQuery("SELECT TIMESTAMP '1582-10-05 00:00:00' + INTERVAL 1 
> DAYS").returns(Timestamp.valueOf("1582-10-06 00:00:00")).check();
> {code}
> Result:
> {code:java}
> class org.apache.ignite.internal.processors.query.IgniteSQLException: Failed 
> to validate query. From line 1, column 25 to line 1, column 41: Illegal DATE 
> literal '1582-10-05': not in format 'yyyy-MM-dd'
> ---
> class org.apache.ignite.internal.processors.query.IgniteSQLException: Failed 
> to validate query. From line 1, column 25 to line 1, column 55: Illegal 
> TIMESTAMP literal '1582-10-05 00:00:00': not in format 'yyyy-MM-dd HH:mm:ss'
> {code}
> *2)* {code:java}
> assertQuery("SELECT DATE '1582-10-01' + INTERVAL 1 
> DAYS").returns(Date.valueOf("1582-10-02")).check();
> ---
> assertQuery("SELECT TIMESTAMP '1582-10-01 00:00:00' + INTERVAL 1 
> DAYS").returns(Timestamp.valueOf("1582-10-02 00:00:00")).check();
> {code}
> Result:
> Doesn't fail, but but the result is incorrect.
> {code:java}
> java.lang.AssertionError: Collections are not equal (position 0):
> Expected: [[1582-10-02]]
> Actual:   [[1582-09-22]]
> ---
> java.lang.AssertionError: Collections are not equal (position 0):
> Expected: [[1582-10-02 00:00:00.0]]
> Actual:   [[1582-09-22 00:00:00.0]]
> {code}
> *3)* OK
> {code:java}
> assertQuery("SELECT DATE '1583-10-05' + INTERVAL 1 
> DAYS").returns(Date.valueOf("1583-10-06")).check();
> ---
> assertQuery("SELECT TIMESTAMP '1583-10-01 00:00:00' + INTERVAL 1 
> DAYS").returns(Timestamp.valueOf("1583-10-02 00:00:00")).check();
> {code}
> The problem is in variation of date conversion in java.util.Date (used in 
> _TypeUtils#fromInterna()_). There is a threshold year 1582 (october).
> https://github.com/AdoptOpenJDK/openjdk-jdk11/blob/19fb8f93c59dfd791f62d41f332db9e306bc1422/src/java.base/share/classes/java/util/Date.java#L1238
> https://github.com/AdoptOpenJDK/openjdk-jdk11/blob/19fb8f93c59dfd791f62d41f332db9e306bc1422/src/java.base/share/classes/java/util/Date.java#L1279
> When Avatica always does trivial calculation using days, milliseconds related 
> to 1970-01-01. 



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

Reply via email to