Skip to content

TIMESTAMP parsing of strings with timezone produces unexpected results #18767

@Jady891213

Description

@Jady891213

What happens?

SELECT '2025-01-01T08:00:00+08'::TIMESTAMP AS c
This implicit conversion is not intuitive

To Reproduce

Image Image Figure 1 shows the result in DuckDB, and Figure 2 shows the result in PostgreSQL. Below is the corresponding SQL query:
SET TIMEZONE TO 'Asia/Shanghai';
SELECT 
    '2025-01-01T00:00:00+00'::TIMESTAMPTZ AS tz_a,
    '2025-01-01T08:00:00'::TIMESTAMPTZ AS tz_b,
    '2025-01-01T08:00:00+08'::TIMESTAMP AS c,
    '2025-01-01T08:00:00+08'::TIMESTAMPTZ::TIMESTAMP AS d;

When DuckDB performs an implicit conversion for column c, if it detects that the string contains timezone information, it first converts the string into a TIMESTAMPTZ and then truncates the timezone, leaving an unexpected and unintuitive local time.
In comparison, PostgreSQL's implicit conversion logic for column c is consistent with the logic of column d, which behaves as expected.
I believe DuckDB's current conversion logic for c is somewhat counterintuitive and may pose potential risks.

OS:

macOS Sequoia 15.5

DuckDB Version:

1.3

DuckDB Client:

1.3

Hardware:

No response

Full Name:

wenjun.zhou

Affiliation:

fenghe

What is the latest build you tested with? If possible, we recommend testing with the latest nightly build.

I have not tested with any build

Did you include all relevant data sets for reproducing the issue?

No - Other reason (please specify in the issue body)

Did you include all code required to reproduce the issue?

  • Yes, I have

Did you include all relevant configuration (e.g., CPU architecture, Python version, Linux distribution) to reproduce the issue?

  • Yes, I have

Metadata

Metadata

Assignees

No one assigned

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions