We read every piece of feedback, and take your input very seriously.
To see all available qualifiers, see our documentation.
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
I've encountered an issue when trying to compare a TIMESTAMP WITH TIME ZONE value with a DATE value. Here's the SQL that reproduces the issue:
TIMESTAMP WITH TIME ZONE
DATE
This works:
set time zone 'UTC'; select date_trunc('day', '2024-05-06 16:09:28+05:00'::timestamptz) == '2024-05-06 17:19:18+05:20'::date as r;
Output:
┌─────────┐ │ r │ │ boolean │ ├─────────┤ │ true │ └─────────┘
But this does not:
set time zone 'UTC'; select date_trunc('day', '2024-05-06 16:09:28+05:00'::timestamptz) >= '2024-05-06 17:19:18+05:20'::date as r;
BinderException: Binder Error: Cannot compare values of type TIMESTAMP WITH TIME ZONE and type DATE - an explicit cast is required
Ubuntu 20.04.5 LTS
0.10.2
python
Arif Aslam
Mammoth Analytics Inc.
I have tested with a stable release
Yes
The text was updated successfully, but these errors were encountered:
Issue duckdb#11959: TIMESTAMPTZ >= DATE
66d7710
Add missing case entry for promoting DATE to TIMESTAMPTZ. This matches PG behaviour. fixes: duckdb#11959 fixes: duckdblabs/duckdb-internal#2001
Merge pull request #11987 from hawkfish/date-to-tstz
7102294
Issue #11959: TIMESTAMPTZ >= DATE
Successfully merging a pull request may close this issue.
What happens?
I've encountered an issue when trying to compare a
TIMESTAMP WITH TIME ZONE
value with aDATE
value. Here's the SQL that reproduces the issue:This works:
Output:
But this does not:
Output:
To Reproduce
OS:
Ubuntu 20.04.5 LTS
DuckDB Version:
0.10.2
DuckDB Client:
python
Full Name:
Arif Aslam
Affiliation:
Mammoth Analytics Inc.
What is the latest build you tested with? If possible, we recommend testing with the latest nightly build.
I have tested with a stable release
Did you include all relevant data sets for reproducing the issue?
Yes
Did you include all code required to reproduce the issue?
Did you include all relevant configuration (e.g., CPU architecture, Python version, Linux distribution) to reproduce the issue?
The text was updated successfully, but these errors were encountered: