The python client seems to ignore system timezone unlike Trino CLI

[RoboticHuman]

I'm using at_timezone in my query but it seems that the session timezone is passed incorrectly to PrestoServer. Adding a local offset in the python script does solve the issue but that's not a solution

[findepi]

@RoboticHuman that's correct, it's not implemented.

You can see in constants.py which headers are supported by the client.

https://github.com/prestosql/presto-python-client/blob/f920129faa26f5e886710ed5c2a2cbbfd182ef1c/presto/constants.py#L32-L43

-- X-Presto-Time-Zone is not one of them.

For the record, here is the list of headers supported by the server

https://github.com/prestosql/presto/blob/fa02de3ba715b6533610f148d9bb45ce44ae8703/presto-client/src/main/java/io/prestosql/client/PrestoHeaders.java#L16-L44

[RoboticHuman]

Thanks for your fast reply @findepi , any expectation of when this can be fixed? I can try to implement it on my end and do a PR if that works too.

[RoboticHuman]

For now I just passed X-Presto-Time-Zone in the http_headers in the Connection. I guess that's a good enough solution till it's properly implemented in case anyone falls for this as well

[findepi]

Challenge is how do we provide the default. The header should be filled with IANA zone id.
The caveat here is that I don't know how to get one in Python standard lib (in Python 2.7 and 3.x)
https://www.python.org/dev/peps/pep-0615/ looks like the future.

@RoboticHuman do you happen to know?

[RoboticHuman]

Yeah I only noticed this problem when I referred to how things are implemented in the Java side, I think your suggestion is right as it needs to fall back properly.

Isn't pytz a good interface for IANA? or you think it's better to wait for the standard lib integration?

[findepi]

I have nothing against pytz, I am more concerned about pulling in a dependency. (The more dependencies we have, more problems for the users.)
We may need to adda depency though...

FWIW pyhive uses python-dateutil (https://pypi.org/project/python-dateutil/) which also does the job.

[ebyhr]

pytz is required module from #168.

cc: @hashhar @mdesmet

[mdesmet]

I actually looked into this a few weeks ago: what is missing from pytz, is the ability to retrieve the local timezone. We would need to either replace pytz or add in another dependency.

We could however easily add in a timezone parameter. WDYT?

Something like:

conn = connect(
    timezone="Europe/Brussels",
    host="<host>",
    port=<port>,
    user="<username>",
    catalog="<catalog>",
    schema="<schema>",
)

[hovaesco]

This is a library that we are looking for http://labix.org/python-dateutil#head-5fb12f4538c5a2fd83f87eea8e6c0ddd47f8b4b0

[mdesmet]

I think we should indeed swap out pytz for python-dateutil. Read more on https://blog.ganssle.io/articles/2018/03/pytz-fastest-footgun.html

[mdesmet]

It seems that python-dateutil is not really what we want. We can't get IANA timezone names out of the tzinfo object.

>>> from dateutil.tz import *
>>> import datetime
>>> datetime.datetime.now(tzlocal()).tzname()
'CEST'

The tzlocal module (not related to above dateutil module) seems to do what we want, it's also compatible with pytz. tzlocal on pypi

>>> from tzlocal import get_localzone
>>> tz = get_localzone()
>>> tz
_PytzShimTimezone(zoneinfo.ZoneInfo(key='Europe/Brussels'), 'Europe/Brussels')
>>> from tzlocal import get_localzone_name
>>> get_localzone_name()
'Europe/Brussels'

In python 3.9 there is also ZoneInfo, however it also not permits us to get the local timezone IANA name.

[ulisesojeda]

right, the tzlocal seems a good candidate. If you guys are OK to include it as a dependency I can implement the feature.