SQL Date Extraction in Grafana Timezone conversion

Grafana Dashboards
1

I’m creating a dashboard for data logged in UTC. However, the data should be viewed in CST using Grafana’s timezone toggle.

This is causing problems with some of my panels. In one of my panels, I am trying to present some dates, which are each associated with a different value (a daily range). When I try extracting the date, I am presented with two problems. I’ve primarily solved the first problem, but am struggling to understand the second.

  1. When I extract the date, the extracted date will be midnight UTC on a certain date, for example UTC 00:00:00 07-08-2026. Because I am choosing to view the data in CST, this date is later converted by Grafana into: CST 18:00:00 07-07-2026.

I’ve tried adding a 6 hour offset, which seems to work except I’ve been presented with some strange date extractions..

  1. What is going on with this date extraction? I’ve also provided the code I used to troubleshoot what timestamps are being extracted to whichever date (with no timestamp offset).

Original Timestamp: 2026-07-08 20:48:15

Extracted Date: 2026-07-09

Code:

SELECT
    timestamp,
    DATE_FORMAT(timestamp, 'yyyy-MM-dd') AS extracted_date,
    TRY_CAST(value AS DOUBLE) * 3785.41 AS val
FROM abcde.abcde.abcde
WHERE $__timeFilter(timestamp)
  AND tag = 'sample_tag'
  AND TRY_CAST(value AS DOUBLE) IS NOT NULL
ORDER BY timestamp;

grafana_date_extraction
grafana_date_extraction1475×302 22.7 KB

2

2026-07-08 20:48:15 becoming 2026-07-09 is not expected from a normal UTC → America/Chicago conversion, so first verify how the timestamp is being interpreted

Check → 

SELECT current_timezone();

and whether timestamp is TIMESTAMP or TIMESTAMP_NTZ? If the column is a TIMESTAMP, the SQL engine may be applying the session timezone before DATE_FORMAT(), which could explain the date rollover.

If the data is stored in UTC and you want the extracted date in America/Chicago, convert it explicitly before formatting:

DATE_FORMAT(
  from_utc_timestamp(timestamp, 'America/Chicago'),
  'yyyy-MM-dd'
) AS extracted_date

Also avoid subtracting a fixed 6-hour offset. America/Chicago observes DST (UTC−5 in July 2026 and UTC−6 in winter), so a hardcoded offset will be incorrect for part of the year. from_utc_timestamp() handles those transitions automatically.

3

The timezone was determined to be “Etc/UTC” from your suggested code:

I also confirmed the data_type was “TIMESTAMP” and not “TIMESTAMP_NTZ” with the following code:


SELECT
    column_name,
    data_type
FROM system.information_schema.columns
WHERE table_catalog = 'table_catalog'
  AND table_schema = 'table_schema'
  AND table_name = 'table_name'
  AND column_name = 'timestamp';
4

Can anyone thing of any other troubleshooting method? I’m at a loss here.

5

what type of database technology are you using for your data: mysql, postgres, ms sql?

what do you see when you hover over the date filter?

image
image841×271 19.8 KB

6

Since current_timezone() returned Etc/UTC and you’ve confirmed the column is a TIMESTAMP, I’d try to find which layer is introducing the date change.

Could you run the same query directly against the database (rather than through Grafana) for that specific row?

SELECT
    timestamp,
    DATE_FORMAT(timestamp, 'yyyy-MM-dd') AS extracted_date
FROM abcde.abcde.abcde
WHERE timestamp = '2026-07-08 20:48:15';

If that returns 2026-07-08, then the SQL engine is producing the expected value and the difference is likely occurring in the datasource or Grafana.

If it returns 2026-07-09, then the SQL engine (or its session configuration) is already producing the shifted date before Grafana receives it.

Which datasource/database you’re using (Databricks, Trino, Athena, Spark SQL, etc.)? The timezone semantics for TIMESTAMP differ between engines, and that will help find the cause.