You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Comparing a timestamp cast to a time zone against a literal returns wrong results #25941
A filter that casts a timestamp without a time zone to one with a time zone, then compares it to a timestamp literal, returns the wrong rows. Both sides of the comparison display the same value. The same comparison against a column instead of a literal gives the right answer.
To Reproduce
CREATETABLEtASVALUES (TIMESTAMP'2024-01-01 10:00:00');
CREATETABLElASSELECT arrow_cast('2024-01-01T10:00:00+05:00', 'Timestamp(Nanosecond, Some("+05:00"))') AS v;
-- Both sides are 2024-01-01T10:00:00+05:00SELECT arrow_cast(column1, 'Timestamp(Nanosecond, Some("+05:00"))') AS lhs, v AS rhs FROM t, l;
-- Compare against a column: 1 row (correct)SELECTcount(*) FROM t, l
WHERE arrow_cast(t.column1, 'Timestamp(Nanosecond, Some("+05:00"))') =l.v;
-- Compare against the same value as a literal: 0 rows (wrong)SELECTcount(*) FROM t
WHERE arrow_cast(column1, 'Timestamp(Nanosecond, Some("+05:00"))')
= arrow_cast('2024-01-01T10:00:00+05:00', 'Timestamp(Nanosecond, Some("+05:00"))');
It also happens with the more common ::timestamptz form when a session time zone is set:
SETdatafusion.execution.time_zone ='+05:00';
CREATETABLEtASVALUES (TIMESTAMP'2024-01-01 10:00:00');
SELECT column1::timestamptzFROM t; -- 2024-01-01T10:00:00+05:00SELECTcount(*) FROM t WHERE column1::timestamptz=TIMESTAMPTZ'2024-01-01 10:00:00+05:00'; -- 0
Expected behavior
Both literal comparisons should return 1, matching the column comparison.
Additional context
Reproduced on main at commit 242b96c. With a +00:00 or UTC time zone the results are correct. With +05:00 or -03:00, the literal comparison returns 0 rows.
While digging into this issue I realized it's the same bug as #25095, just triggered a bit differently. It uses a fixed-offset time zone like +05:00 or -03:00 instead of a named zone like Asia/Singapore. For example:
CREATETABLEtASVALUES (TIMESTAMP'2024-01-01 10:00:00');
SELECTcount(*) FROM t
WHERE arrow_cast(column1, 'Timestamp(Nanosecond, Some("+05:00"))')
= arrow_cast('2024-01-01T10:00:00+05:00', 'Timestamp(Nanosecond, Some("+05:00"))');
-- returns 0 on main, should be 1
The root cause is the same: the unwrap_cast rewrite copies the literal's value without applying the timezone shift.
I applied the change from #25099 on top of current main (6e319bddd) and ran all the queries from this issue. They return the right results now.
Since #25099 fixes both issues, could you add Closes #25941 to its description? That way both get closed when it merges.
On current main (9411463), this issue seems to be solved, the following SLT tests passes:
statement ok
CREATE TABLE t AS VALUES (TIMESTAMP '2024-01-01 10:00:00');
statement ok
CREATE TABLE l AS SELECT arrow_cast('2024-01-01T10:00:00+05:00', 'Timestamp(Nanosecond, Some("+05:00"))') AS v;
# Both sides are 2024-01-01T10:00:00+05:00
query PP
SELECT arrow_cast(column1, 'Timestamp(Nanosecond, Some("+05:00"))') AS lhs, v AS rhs FROM t, l;
----
2024-01-01T10:00:00+05:00 2024-01-01T10:00:00+05:00
# Compare against a column: 1 row (correct)
query I
SELECT count(*) FROM t, l
WHERE arrow_cast(t.column1, 'Timestamp(Nanosecond, Some("+05:00"))') = l.v;
----
1
query I
SELECT count(*) FROM t
WHERE arrow_cast(column1, 'Timestamp(Nanosecond, Some("+05:00"))')
= arrow_cast('2024-01-01T10:00:00+05:00', 'Timestamp(Nanosecond, Some("+05:00"))');
----
1
statement ok
SET datafusion.execution.time_zone = '+05:00';
statement ok
CREATE TABLE t2 AS VALUES (TIMESTAMP '2024-01-01 10:00:00');
# 2024-01-01T10:00:00+05:00
query P
SELECT column1::timestamptz FROM t2;
----
2024-01-01T10:00:00+05:00
# 0
query I
SELECT count(*) FROM t2 WHERE column1::timestamptz = TIMESTAMPTZ '2024-01-01 10:00:00+05:00';
----
1
statement ok
RESET datafusion.execution.time_zone;
statement ok
DROP TABLE t;
statement ok
DROP TABLE l;
statement ok
DROP TABLE t2;
Activity
DHRUV6029 commentedon Oct 5, 2026
take
DHRUV6029 commentedon Oct 5, 2026
Hi @Ruchirtripathi, thanks for working on #25099!
While digging into this issue I realized it's the same bug as #25095, just triggered a bit differently. It uses a fixed-offset time zone like
+05:00or-03:00instead of a named zone likeAsia/Singapore. For example:The root cause is the same: the unwrap_cast rewrite copies the literal's value without applying the timezone shift.
I applied the change from #25099 on top of current main (
6e319bddd) and ran all the queries from this issue. They return the right results now.Since #25099 fixes both issues, could you add
Closes #25941to its description? That way both get closed when it merges.Thanks!
AdamGS commentedon Nov 2, 2026
On current main (9411463), this issue seems to be solved, the following SLT tests passes:
test: Add regression tests for some `unwrap_cast` related bugs that d…