Return double with correct precision for UNIX_TIMESTAMP

[yuancu]

Description

When UNIX_TIMESTAMP is fed with a timestamp string, it could not return a correct double value since the string is implicitly cast to date before feeding to the function.

Deprecated solution:
I corrected this behavior by adding STRING as an acceptable type to UNIX_TIMESTAMP and adding corresponding handlers for strings. It is worth noting that timestamp string is mentioned as an acceptable argument in the documentation:
The date argument may be a DATE, or TIMESTAMP string
Therefore, The change to the function signature should be appropriate.

I reordered the signatures of UNIX_TIMESTAMP so that unix_timestamp(timestamp) will be prioritized when the input is a string. In such case, the string will be cast to a timestamp. The reordering is valid since this coercion should also be compatible with date and time types and will result in correct values for these types.

Related Issues

Resolves #3611

Check List

• New functionality includes testing.
• New functionality has been documented.
• New functionality has javadoc added.
• New functionality has a user manual doc added.
• API changes companion pull request created.
• Commits are signed per the DCO using --signoff.
• Public documentation issue/PR created.

By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.
For more information on following Developer Certificate of Origin and signing off your commits, please check here.

[dai-chen]

Just wondering how did we decide to fix these cases one by one instead of adding an implicit conversion from String to Timestamp?

[LantaoJin]

Just wondering how did we decide to fix these cases one by one instead of adding an implicit conversion from String to Timestamp?

+1. @yuancu I have mentioned it multiple times, could you make it happen before 3.1.0? We'd better not to extend original function definitions.

For this case, the timestamp string should implicitly cast to timestamp instead of date.

[yuancu]

Just wondering how did we decide to fix these cases one by one instead of adding an implicit conversion from String to Timestamp?

+1. @yuancu I have mentioned it multiple times, could you make it happen before 3.1.0? We'd better not to extend original function definitions.

Do you mean when we find a type mismatch, we coerce it to timestamp instead of date?

[LantaoJin]

Just wondering how did we decide to fix these cases one by one instead of adding an implicit conversion from String to Timestamp?

+1. @yuancu I have mentioned it multiple times, could you make it happen before 3.1.0? We'd better not to extend original function definitions.

Do you mean when we find a type mismatch, we coerce it to timestamp instead of date?

It depends on what the format of string is. 2020-01-01 or 2020-01-01 00:00:00

[yuancu]

Ok I get it. I'll try to fix it.

Update: The functions are resolved based on the distance between input argument types and expected argument types.
unix_timestamp expects date / timestamp / double or no input.
When the input is of string type, its distance to date / timestamp are the same. It picks the definition that is defined earlier. For now, we prioritize unix_timestamp(timestamp) over unix_timestamp(date) as timestamp allows a wider range of inputs -- date / time / timestamp string can be cast to timestamp.

TODO:

• Implement literal cast: e.g. literal "2001-10-10" can be implicitly cast to a date, "2001-10-10 13:29:09" can be implicitly cast to a timestamp.
• Allow casting date/time string to timestamp [BUG] CAST does not support casting date/time string to timestamp #3728

[LantaoJin]

@yuancu could your resolve the conflicts?

[yuancu]

@yuancu could your resolve the conflicts?

No problem.

[LantaoJin]

LGTM, waiting CI pass

[qianheng-aws]

@yuancu Do we have issue to track supporting implicit type coercion in v3? If not, please create a one and attach the ignored test there.

[yuancu]

@yuancu Do we have issue to track supporting implicit type coercion in v3? If not, please create a one and attach the ignored test there.

#3761 is created.