fix: Address time zone localization issue #367
Closed
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Description
This PR addresses #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
TimeWithTimeZoneValueMapper
works (or doesn't work).Specifically, the following Trino query,
returns
18:00:00-07:00
when 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: