datafusion.execution.time_zone is not used for basic time zone inference

[adriangb]

Describe the bug

I would expect that setting SET datafusion.execution.time_zone = '+08:00' would lead to SELECT '2024-11-01T00:00:00.0+00:00'::timestamptz - '2024-11-01T00:00:00.0'::timestamp to give 8 hours (that is, the same as SELECT '2024-11-01T00:00:00.0+00:00'::timestamptz - '2024-11-01T00:00:00.0+08:00'::timestamptz). Some things do work e.g. SELECT '2024-11-01T00:00:00.0'::timestamptz does give 2024-11-01T00:00:00+08:00.

To Reproduce

No response

Expected behavior

No response

Additional context

No response

[adriangb]

cc @alamb I think you've written some tests for datafusion.execution.time_zone based on blames, I couldn't track down who originally implemented it

[alamb]

Hi @adriangb -- I am not sure who originally implemented it either. I think @Omega359 was thinking about how to specify / pass the default timezones to functions recently too

[Omega359]

Yes, it's been on my radar for a while now. There are a number of issues around tz's some of which are generic tz issues, others are issues where using the default tz in config might be useful. A small but not complete list

• Make from_unixtime aware of execution timezone #12892
• Casting existing timestamp to timestamp again strips timezone information #12218 (comment)
• Better timezone functionalities #10368
• Support date_bin on timestamps with timezone, properly accounting for Daylight Savings Time #10602

[jonathanc-n]

Someone can probably take a look at #13130, it seems to be done it just has a doc check error

[alamb]

This may now be feasible after

• Add SessionConfig reference to ScalarFunctionArgs #13519