You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues-all@impala.apache.org by "Fifteen (Jira)" <ji...@apache.org> on 2020/08/19 03:21:00 UTC

[jira] [Assigned] (IMPALA-9922) Is this a better approach to deal with malformed input in 'to_timestamp()'

     [ https://issues.apache.org/jira/browse/IMPALA-9922?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Fifteen reassigned IMPALA-9922:
-------------------------------

    Assignee: abeltian  (was: Fifteen)

> Is this a better approach to deal with malformed input in 'to_timestamp()'
> --------------------------------------------------------------------------
>
>                 Key: IMPALA-9922
>                 URL: https://issues.apache.org/jira/browse/IMPALA-9922
>             Project: IMPALA
>          Issue Type: Improvement
>          Components: Backend
>    Affects Versions: Impala 3.4.0
>            Reporter: Fifteen
>            Assignee: abeltian
>            Priority: Minor
>              Labels: newbie, ramp-up
>
> When I tried to convert `string` to `timestamp` with `to_timestamp()` function, I got some unexpected NULL values . So I am writing this issue to seek for your help. 
> Currently, the built-in function `to_timestamp()` return NULL when input's length is not equal to the length of format string describes. For example, the following query returns `NULL`:
> {code:java}
> [impala-shell]default> select to_timestamp("2020-01-01 18:00:00.12","yyyy-MM-dd HH:mm:ss.SSS")
> > NULL{code}
> While this query returns converted value:
> {code:java}
> [impala-shell]default> select to_timestamp("2020-01-01 18:00:00.123","yyyy-MM-dd HH:mm:ss.SSS") 
> > 2020-01-01 18:00:00.123000000{code}
>  
> Snippet below explains the relative logic. The file name is `cast-functions-ir.cc` 
> {code:java}
> bool ParseDateTime(const char* str, int str_len, const DateTimeFormatContext& dt_ctx,
>     DateTimeParseResult* dt_result) {
>   DCHECK(dt_ctx.fmt_len > 0);
>   DCHECK(dt_ctx.toks.size() > 0);
>   DCHECK(dt_result != NULL);
>   //-------------------------------------------------------
>   // if str_len < fmt_len, Parse fail and return NULL 
>  //-------------------------------------------------------
>   if (str_len <= 0 || str_len < dt_ctx.fmt_len || str == NULL) return false; 
>   StringParser::ParseResult status;
>   ...
> {code}
> h3.  *My proposal* 
> Will it be better if  function accepts the shorter input and returns converted timestamp with some padding zeros?  i.e. returns 2020-01-01 18:00:00.012000000 with the following sql
> {code:java}
> [impala-shell]default> select to_timestamp("2020-01-01 18:00:00.12","yyyy-MM-dd HH:mm:ss.SSS")
> {code}
>  
>  



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

---------------------------------------------------------------------
To unsubscribe, e-mail: issues-all-unsubscribe@impala.apache.org
For additional commands, e-mail: issues-all-help@impala.apache.org