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

Rong Rong commented on FLINK-11935:
-----------------------------------

Thanks for checking in [~yanghua]. I think we can skip the calcite upgrade to 
1.19 because the file did not change between 1.18 and 1.19 i believe.

I think further investigation is needed to answer: "can we remove DateTimeUtils 
file".

if removing DateTimeUtils and fix the cast problem is possible we can just go 
with that path. (as you described)

if not, we will need to
 # backport the DateTimeUtils to latest version Flink use (which is 1.18),
 # make changes on top as needed
 # create Calcite/Avatica Jira ticket and marked in the DataTimeUtils file to 
properly log the issue why we still need the file.

Once we upgrade to 1.19 in the master ticket FLINK-11921. we will revisit and 
see if removing the file is possible during the main upgrade, if not a follow 
up ticket will be created.

 

Do you think this can be the right approach? 

> Remove DateTimeUtils pull-in and fix datetime casting problem
> -------------------------------------------------------------
>
>                 Key: FLINK-11935
>                 URL: https://issues.apache.org/jira/browse/FLINK-11935
>             Project: Flink
>          Issue Type: Sub-task
>          Components: Table SQL / API
>            Reporter: Rong Rong
>            Assignee: vinoyang
>            Priority: Major
>
> This {{DateTimeUtils}} was pulled in in FLINK-7235.
> Originally the time operation was not correctly done via the {{ymdToJulian}} 
> function before the date {{1970-01-01}} thus we need the fix. similar to 
> addressing this problem:
> {code:java}
>  Optimized :1017-12-05 22:58:58.998 
>  Expected :1017-11-29 22:58:58.998
>  Actual :1017-12-05 22:58:58.998
> {code}
>  
> However, after pulling in avatica 1.13, I found out that the optimized plans 
> of the time operations are actually correct. it is in fact the casting part 
> that creates problem:
> For example, the following:
> *{{(plus(-12000.months, cast('2017-11-29 22:58:58.998', TIMESTAMP))}}*
> result in a StringTestExpression of:
> *{{CAST(1017-11-29 22:58:58.998):VARCHAR(65536) CHARACTER SET "UTF-16LE" 
> COLLATE "ISO-8859-1$en_US$primary" NOT NULL}}*
> but the testing results are:
> {code:java}
>  Optimized :1017-11-29 22:58:58.998
>  Expected :1017-11-29 22:58:58.998
>  Actual :1017-11-23 22:58:58.998
> {code}
>  



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

Reply via email to