Consider timezones with UTC and +00:00 to be the same

[marvinlanhenke]

Which issue does this PR close?

Closes #10957.

Rationale for this change

Timezone was specified as "+00:00" instead of "UTC". This caused a missmatch in temporal_coercion.

What changes are included in this PR?

Are these changes tested?

Are there any user-facing changes?

[marvinlanhenke]

@alamb PTAL.

Since "+00:00" and "UTC" are the 'same' - is this viable? Or do we have to extend the logic here in order to provide both variants (and possibly not introduce a breaking change)?

[alamb]

I responded on #10957 (comment)

[erratic-pattern]

Since "+00:00" and "UTC" are the 'same' - is this viable? Or do we have to extend the logic here in order to provide both variants (and possibly not introduce a breaking change)?

+1 on including type coercion logic for "UTC" and "+00:00" and leaving the signature of NowFunc unchanged. This would fix the error described in #10957 more generally without introducing any breaking changes

[marvinlanhenke]

...perhaps someone can help me out on this. I still haven't found a way to create a timestamp with timezone in order to create a proper sqllogictest.

[alamb]

...perhaps someone can help me out on this. I still haven't found a way to create a timestamp with timezone in order to create a proper sqllogictest.

There are some examples here: #10602

You can also use arrow_cast (there are some examples here https://datafusion.apache.org/user-guide/sql/scalar_functions.html#arrow-cast)

[marvinlanhenke]

I think this should be fixed now. I added some sqllogictest as well to validate the new behavior - thanks @alamb for the pointer on arrow_cast. PTAL @alamb @erratic-pattern

[alamb]

Thank you @marvinlanhenke and @samuelcolvin -- this looks good to me

cc @waitingkuo

[alamb]

I added some additional comments and merged up from main.

@erratic-pattern if you have time, it would be great if you could review this PR as well

[alamb]

Thanks everyone!