THIS IS A TEST INSTANCE. ALL YOUR CHANGES WILL BE LOST!!!!
...
All of those way are valid because SQL:2011 does not specify the function return type and every SQL engine vendor has its own implementation[2], for example CURRENT_TIMESTAMP.
NOTE: Flink supports TIME-related types with precision well, all example in this FLIP the precision just retains to seconds for simplification purpose.
| function | flink current behavior | flink proposed changes | other SQL vendors' behavior |
| CURRENT_TIMESTAMP | #session timezone: UTC 2020-12-28T23:52:52 #session timezone: UTC+8 2020-12-28T23:52:52 wall clock: UTC+8:2020-12-29 07:52:52 | #session timezone: UTC 2020-12-28T23:52:52 #session timezone: UTC+8 2020-12-29T07:52:52 | In MySQL, Spark, the function NOW() and CURRENT_TIMESTAMP return current timestamp value in session time zone，the return type is TIMESTAMP In Pg, Presto, the function NOW() and CURRENT_TIMESTAMP return current timestamp in session time zone，the return type is TIMESTAMP WITH TIME ZONE In Snowflake the function CURRENT_TIMESTAMP/LOCALTIMESTAMP return current timestamp in session time zone，the return type is TIMESTAMP WITH LOCAL TIME ZONE |
...
This is an incompatible change, we introduce SQL/API option table.exec.fallback-legacy-time-function for compacting current wrong behavior, and set it to ‘false’. If users want to keep the legacy behavior, they need to set it this option value to ’true’ manually, this would be add to release note.
...
2. Change the return type of function CURRENT_TIMESTAMP/NOW()/PROCETIME() to TIMESTAMP WITH LOCAL TIME ZONE. This proposal will lead to a embarrassed situation for function CURRENT_TIME, because no DB vendor use type TIME WITH LOCAL TIME ZONE yet, and the time semantic of TIMESTAMP WITH LOCAL TIME ZONE is instant which is too complex to understand for normal users.
References
...
...