Disallow timestamp w/ tz values that fall in DST gap or are ambiguous

[martint]

Operations that result in timestamp w/ tz values that fall in the DST gap or that are ambiguous because of DST transitions should fail with an error.

[findepi]

Example of an ambiguous value due to DST backwards transition

presto> SELECT from_unixtime(1603589478, 'UTC') AT TIME ZONE 'Europe/Warsaw';
                 _col0
---------------------------------------
 2020-10-25 02:31:18.000 Europe/Warsaw

but:

presto> SELECT from_unixtime(1603589478, 'UTC') AT TIME ZONE 'Europe/Warsaw' = TIMESTAMP '2020-10-25 02:31:18.000 Europe/Warsaw';
 _col0
-------
 false

[dain]

I thought we decided we were using the "lax" rules everywhere in Presto. In that case, gaps get pushed +1 hr, and I don't remember what is chosen for double. If we are changing this, I expect it will be a big deal to implement this everywhere.

[martint]

I don't remember ever deciding that, but it's very problematic. It screws up with optimizations the engine could do and produces surprising (incorrect) results, as in the example above.