john-bodley
commented
1 year ago Per this article I wonder if there's merit in removing pytz in favor of dateutil.tz which since Python 3.6 remedies ambiguous datetimes due to daylight saving time transition.
Description
This PR addresses https://github.com/trinodb/trino-python-client/issues/366.
Note @mdesmet et al. it doesn't address the time zone conundrum with fractional times or times (as opposed to timestamps). Additionally I sense there's an issue with how the
TimeWithTimeZoneValueMapperworks (or doesn't work).Specifically, the following Trino query,
returns
18:00:00-07:00when run on 2023-04-28 when daylights savings is in effect for said time zone. In order to resolve this query (I presume) the Trino server has had to taken has taken into account the current date on the server to "anchor" the time, i.e., if one were to run the same query on 2023-01-01 when daylights savings in not in effect the result would be17:00:00-08:00.The issue is the mapping that @mdesmet outlined is running on the Trino client—which is pseudo agnostic* of the server's timezone—and may be in a different timezone (and thus date) than the Trino server. The problem seems ill-defined, i.e., when mapping this to a Python object localized to a timezone without a numerical offset, i.e., America/Los_Angeles, one first needs to know the underlying date.
* Granted the client isn't completely agnostic of the current date on the server, i.e., it can be determined via
SELECT current_date, however this requires an additional query and there's no guarantee this will be executed on the same date as the primary query.Non-technical explanation
Release notes
( ) This is not user-visible or docs only and no release notes are required. ( ) Release notes are required, please propose a release note for me. ( ) Release notes are required, with the following suggested text: