Improve the way TO_TIME and TO_TIMESTAMP are translated.
When called with an explicit format, said format is properly translated (for instance, SF's format YYYY-MM-DD HH24:MITZH:TZM gets translated into DB's yyyy-MM-dd'T'HH:mmZZZ), be it a constant or a variable.
When SF's TO_TIMESTAMP is called with the TO_TIMESTAMP ( <numeric_expr> , <scale> ) we simply truncate numeric_expr to a number-of-seconds-since-epoch, as it seems to be the best we can do.
When TO_TIMESTAMP is called with no explicit format, we do our best as to handle the automatic formats that SF handles but DB doesn't by trying each explicitly until one matches
the DY format part (corresponding to EEE in DB), ie. day-of-week, isn't allowed anymore since Spark 3.0. Since it isn't relevant in figuring out a specific point in time, we simply ignore it in both translated format and input string (resulting in huge amount of SQL being produced, see tests/resources/functional/snowflake/core_engine/functions/conversion/to_timestamp_variable_format.sql for an example)
Improve the way
TO_TIME
andTO_TIMESTAMP
are translated.YYYY-MM-DD HH24:MITZH:TZM
gets translated into DB'syyyy-MM-dd'T'HH:mmZZZ
), be it a constant or a variable.TO_TIMESTAMP ( <numeric_expr> , <scale> )
we simply truncatenumeric_expr
to a number-of-seconds-since-epoch, as it seems to be the best we can do.DY
format part (corresponding toEEE
in DB), ie. day-of-week, isn't allowed anymore since Spark 3.0. Since it isn't relevant in figuring out a specific point in time, we simply ignore it in both translated format and input string (resulting in huge amount of SQL being produced, seetests/resources/functional/snowflake/core_engine/functions/conversion/to_timestamp_variable_format.sql
for an example)