Remove support for political time zones from TIME WITH TIME ZONE

[findepi]

TIME WITH TIME ZONE can express such (probably) useful things like 02:23:00+02:00 (= pair of 23 minutes past 2am, offset +2h).
However, it can also represent such things like 02:23:00 Europe/Warsaw, which sounds like a cool feature at first, but its semantics are problematic -- you can't reliably convert this to TIME in any zone (like UTC), since a named zone doesn't need to have fixed zone offset (due to DST and policy changes over time). (Probably for these reasons, Java Time API has LocalTime and OffsetTime but nothing like ZonedTime exists.)

As discussed offline some time ago, we should:

• limit TIME WITH TIME ZONE to offset zones only.

Some details:

• TIME '.... Continent/City' and TIME '.... PST' literals should fail
• TIME / TIME TZ at time zone .... should fail for non-offset tz
• cast(timestamp tz as time tz) should take current (as of this timestamp’s instant) tz offset and produce time with tz offset
• cast(time as time tz) should take current session time zone’s current offset and produce time with tz offset
• in JDBC, time with time zone should be represented as OffsetTime

[noahkawasakigoogle]

Hey all, I've got a question on this I'm hoping you can help with. I work at Looker/Google so I am trying to update our SQL syntax for timezones based on the newer versions of this change.

Our timezone implementations for conversion use the named timezones -- 'America/Los_Angeles'. So a lot of our SQL looks like:

(CAST(CURRENT_DATE AS TIMESTAMP) AT TIME ZONE 'UTC')

and such.

Looks like this issue was intended to remove support for those values. But I think I also might be misinterpreting. Does this mean named values should never be used in Trino/PrestoSQL syntax anymore? And everything should be using offsets like -08?

Because these queries still work on 341+:

[martint]

Political timezones are still supported for the TIMESTAMP(p) WITH TIME ZONE type. This was just about removing it for TIME(p) WITH TIME ZONE, as the semantics are not well defined when there's no date component.

[noahkawasakigoogle]

Ahh, thank you very much. I should read more carefully 😄