What's the reasoning behind this test case change? If the time range is:

start=2023-11-05T05:00:00.000Z
end=2023-11-05T05:00:01.000Z

then you'd expect it to return a timestamp that is inside the time range in UTC?

Do I have this mapping right?

• 4:00 UTC is 0:00 in New York
• 5:00 UTC is 1:00 in New York
• 6:00 UTC is 1:00 in New York
• 7:00 UTC is 2:00 in New York

So asking for the time between 5:00 and 5:01 UTC should still give 5:00 UTC, not 6:00 UTC? However if it was asking for the time between 1:00 and 1:01 New York, then it would be acceptable to return 6:00 UTC (although ideally, it should return two rows, both 5:00 UTC and 6:00 UTC).

The timezone is America/New_York in the test case, and duckdb seems to be resolving 1:00 America/New_York as 6:00 UTC instead of 5:00.

Actually it relates to this change as well on line 435 below.

I agree It does look odd though, can try around rewriting range query for duckdb but not sure if it would work. Last option is to always create a manual inline query like we do for other olaps.

Let me know your view on this if we should try changing it further or use olap approach if change does not work or just keep it this way.

Yeah there were cases that were not taken care of when passing UTC values, I will need to revisit it.

It does not seem to be working for this simple case

SELECT timezone('America/Los_Angeles', range) AS "timestamp" FROM range('2024-03-10T08:00:00Z'::TIMESTAMP, '2024-03-13T07:00:00Z'::TIMESTAMP, INTERVAL '1 DAY');
┌──────────────────────────┐
│        timestamp         │
│ timestamp with time zone │
├──────────────────────────┤
│ 2024-03-10 15:00:00+00   │
│ 2024-03-11 15:00:00+00   │
│ 2024-03-12 15:00:00+00   │
└──────────────────────────┘

expected 2024-03-10 08:00:00+00, 2024-03-11 07:00:00+00 and 2024-03-12 07:00:00+00. Also tried

SELECT range AT TIME ZONE 'America/New_York' AS "timestamp" FROM range('2023-11-05T05:00:00Z'::TIMESTAMPTZ AT TIME ZONE 'America/New_York', '2023-11-05T05:01:00Z'::TIMESTAMPTZ AT TIME ZONE 'America/New_York', INTERVAL '1 MINUTE');
┌──────────────────────────┐
│        timestamp         │
│ timestamp with time zone │
├──────────────────────────┤
│ 2023-11-05 06:00:00+00   │
└──────────────────────────┘

So its a duckdb thing where is interprets 01:00 as 06:00

D SELECT range AT TIME ZONE 'America/New_York' AS "timestamp" FROM range('2023-11-05T05:00:00Z'::TIMESTAMPTZ AT TIME ZONE 'America/New_York', '2023-11-05T05:00:01Z'::TIMESTAMPTZ AT TIME ZONE 'America/New_York', INTERVAL '1 SECOND');
┌──────────────────────────┐
│        timestamp         │
│ timestamp with time zone │
├──────────────────────────┤
│ 2023-11-05 06:00:00+00   │
└──────────────────────────┘
D SELECT range  AS "timestamp" FROM range('2023-11-05T05:00:00Z'::TIMESTAMPTZ AT TIME ZONE 'America/New_York', '2023-11-05T05:00:01Z'::TIMESTAMPTZ AT TIME ZONE 'America/New_York', INTERVAL '1 SECOND');
┌─────────────────────┐
│      timestamp      │
│      timestamp      │
├─────────────────────┤
│ 2023-11-05 01:00:00 │
└─────────────────────┘

In your assessment, how does this impact the correctness of the output charts/values? Our desired behavior is to have a bin for every hour, so ideally on DST days we'd output either 23 or 25 bins (in the case of 25, there would be two bins with the same label after each other).

I checked and see that now there would be 23 or 25 bins depending on time going backwards or forwards. Earlier there were always 24 bins. I don't see any broken chart because of it around the time change.

However, I do see now chart skips the time bin at which time goes backwards in Nov which is consistent with the data sent (does not break the chart though). In case of time going forwards in March, chart skips the time bin in both new and pushdown implementation so a UI quirk.