Timezones

How Lightdash handles timezones in date filters, grouping, and display, what settings are available, and how to work around common timezone issues.

How Lightdash uses timezones

When you apply a relative date filter like “today”, “last 1 completed day”, or “in the current month”, Lightdash needs to determine what “today” means. By default, Lightdash uses UTC for all relative date filter calculations.

This means that for a user in California (Pacific Time, UTC-8), “today” rolls over at 4:00 PM local time because that’s when midnight UTC occurs. This applies to all relative date filters - “yesterday”, “in the current week”, “last 7 completed days”, etc.

Absolute date filters (e.g., “equals 2026-01-15” or “is between 2026-01-01 and 2026-01-31”) are not affected by timezone settings since you’re specifying exact dates.

What happens under the hood

When a relative date filter is applied, Lightdash:

1. Gets the current time in UTC (or the configured timezone - see Timezone settings)
2. Calculates the start and end of the requested period (e.g., start of yesterday, end of yesterday)
3. Converts those boundaries to UTC timestamps
4. Generates a SQL WHERE clause using those boundaries

For example, “last 1 completed day” queried on Feb 13 at 3 PM UTC becomes:

WHERE date >= '2026-02-12' AND date < '2026-02-13'

For the full list of date filter types and their SQL output, see the Date/Timestamp Filter Reference Guide.

Timezone settings in Lightdash

Lightdash has two separate timezone settings that solve different problems at different layers:

Setting	Layer	Question it answers	Where configured
Project timezone	Application	”What timezone should my users see data in?”	Project settings → Timezone
Data timezone	Warehouse	”What timezone are my NTZ timestamps stored in?”	Warehouse connection → Advanced settings

Availability: The expanded project-timezone behavior (display formatting, DATE_TRUNC grouping, calendar extracts), the convert_timezone dimension override, and the data timezone are all Experimental features behind the EnableTimezoneSupport flag. Reach out to support to enable it for your organization. Without the flag, the project timezone only controls relative date filter boundaries.

For relative date filter calculations, Lightdash resolves the project timezone using the following hierarchy (highest priority first):

1. Per-chart timezone - set on an individual chart in the Explore view
2. Project query timezone (UI setting) - set by an admin in the project settings UI
3. LIGHTDASH_QUERY_TIMEZONE environment variable - server-wide fallback
4. UTC - default if nothing else is configured

Per-chart timezone picker

You can override the query timezone for an individual chart in the Explore view. When building or editing a chart, use the timezone picker to select a timezone. This only applies to that specific chart and takes the highest priority in the hierarchy.

Project query timezone (UI setting)

Organization and project admins can set a default query timezone for the project in Settings > Project Settings.

Unless overridden by a per-chart timezone, this setting controls:

• Relative date filter boundaries - what “today”, “yesterday”, “in the current month” mean
• Time-based grouping - DATE_TRUNC intervals (DAY, WEEK, MONTH, QUARTER, YEAR) bucket rows on project-timezone calendar boundaries
• Calendar component extracts - DAY_OF_WEEK_INDEX, DAY_OF_WEEK_NAME, DAY_OF_MONTH_NUM, DAY_OF_YEAR_NUM, WEEK_NUM, MONTH_NUM, MONTH_NAME, QUARTER_NUM, QUARTER_NAME, YEAR_NUM, HOUR_OF_DAY_NUM, MINUTE_OF_HOUR_NUM are computed in the project timezone, so a “Day of week” or “Month number” dimension grouped next to a DATE_TRUNC sibling lines up on the same calendar
• Result display - table cells, chart axes, tooltips, and CSV/Excel/Google Sheets exports format timestamps in the project timezone, with the resolved zone shown as a badge on the chart card

Truncated intervals and extracts on a date-typed base dimension (e.g. order_date_month where order_date is type: date) skip the timezone shift. A date value carries no time component, so it always renders as the calendar date it represents.

This is the recommended way to configure the query timezone for most teams.

Individual dimensions can opt out of project-timezone formatting using convert_timezone: false. See Per-dimension display opt-out below.

LIGHTDASH_QUERY_TIMEZONE environment variable

The environment variable LIGHTDASH_QUERY_TIMEZONE sets a server-wide default timezone for all relative date filter calculations. It applies to all users and all projects on the instance, but is overridden by both the UI setting and per-chart timezone.

• Self-hosted: Set this environment variable directly on your instance.
• Lightdash Cloud (Pro/Enterprise): Contact us and we can configure this for your instance.

If you have both the UI setting and the environment variable configured, the UI setting takes priority.

Per-dimension display opt-out

By default, every timestamp dimension follows the project timezone for display, grouping, and extracts. Some columns - system timestamps, audit logs, pre-converted values - should render in their raw warehouse value instead. Set convert_timezone: false on the dimension’s YAML meta to opt that single column out:

dbt v1.9 and earlier

columns:
  - name: created_at_utc
    meta:
      dimension:
        type: timestamp
        convert_timezone: false

dbt v1.10+ and Fusion

columns:
  - name: created_at_utc
    config:
      meta:
        dimension:
          type: timestamp
          convert_timezone: false

Lightdash YAML

dimensions:
  - name: created_at_utc
    type: timestamp
    convert_timezone: false

The override propagates to every time-interval child of the base dimension (_day, _month, _day_of_week_index, _month_num, …), so all of them render in the raw warehouse value.

The flag affects display only - table cells, exports, DATE_TRUNC grouping, and EXTRACT-based intervals all skip the project-timezone shift. Filter rendering still converts boundaries into the project timezone, so absolute date filters on a convert_timezone: false column may behave surprisingly: the user sees raw warehouse values but filter literals are bound to project-timezone midnights. We recommend flagging this trade-off in the dimension’s description when you opt out.

Data timezone

The data timezone answers a different question than the project timezone: “what timezone are my NTZ (no-timezone) timestamps actually stored in?”

Set the data timezone on a warehouse connection (Warehouse connection → Advanced settings → Data timezone) and Lightdash issues the appropriate session command on each query (e.g. SET timezone TO 'America/Chicago' on Postgres, ALTER SESSION SET TIMEZONE = 'America/Chicago' on Snowflake). Ambiguous NTZ values are then interpreted in that zone before being compared to filter literals or grouped.

• Without it: a stored 2024-01-15 18:00:00 in an NTZ column is assumed to be UTC.
• With America/Chicago: the warehouse reads it as 6pm Chicago - midnight UTC the next day.

Scheduled delivery timezone

Project admins can set a default timezone for scheduled deliveries in Project Settings > Syncs & Scheduled Deliveries. Users can also override the timezone per individual delivery.

This setting only controls when the scheduled delivery runs. It does not change how queries interpret dates - relative date filters use the query timezone hierarchy described above.

Per-user query timezone

There is currently no way for individual users to set their own timezone for query calculations. If this is important to you, upvote or comment on these open GitHub issues:

• I want to be able to enable user-specific time zones (#5923)
• I want to see timestamps in my local timezone rather than in UTC (#2921)

Common timezone issues and workarounds

”Today” or “yesterday” shows unexpected data

This is the most common timezone-related issue. If you’re in a timezone behind UTC, relative date filters like “today” and “last 1 completed day” will roll over before your local midnight. For example, a user in California (UTC-8) filtering for “last 1 completed day” at 3 PM Pacific on Feb 13:

• In UTC, it’s already Feb 14
• Lightdash calculates “last 1 completed day” as Feb 13 (UTC)
• But the user expects “yesterday” to be Feb 12 in their local time
• The entire day window is offset by 8 hours

This isn’t just a few rows being shifted - the filter boundaries are a full day off from what you’d expect.

Workarounds:

• Set the project query timezone: An admin can set the query timezone in Settings > Project Settings to match your team’s timezone. See Project query timezone.

• Use the per-chart timezone picker: Override the timezone on a specific chart in the Explore view. See Per-chart timezone picker.

• Set LIGHTDASH_QUERY_TIMEZONE: Set the LIGHTDASH_QUERY_TIMEZONE environment variable to your preferred timezone. Available for self-hosted instances, or contact us for Lightdash Cloud (Pro/Enterprise).

• Cast to date in dbt: If you only need day-level granularity, cast your timestamp column to a date type in your dbt model. When a column uses type: date, there’s no time component for Lightdash to apply UTC conversion to - 2026-02-12 is just 2026-02-12 regardless of timezone.

  -- In your dbt model
  select
    created_at::date as created_date
  from your_table
  

  Then in your Lightdash YAML, set type: date for this dimension.

  The tradeoff is that you lose intraday granularity - you won’t be able to group by hour or minute on this dimension.

• Use absolute date filters: If you know the exact dates you want, use absolute filters (e.g., “is between 2026-02-12 and 2026-02-13”) instead of relative ones. These are not affected by timezone.

Timestamps are stored in a specific timezone and you don’t want Lightdash to change them

If your timestamps are stored in a local timezone (e.g., US Pacific Time) without timezone metadata, Lightdash still applies UTC-based filter logic by default. This can cause date filter boundaries to not line up with your data.

Workarounds:

• Set the data timezone on the warehouse connection: If EnableTimezoneSupport is enabled for your organization, set the data timezone on the warehouse connection to match the zone your NTZ timestamps are stored in. Lightdash will issue the appropriate session command so ambiguous NTZ values get interpreted correctly. Not available for BigQuery or Athena.
• Cast to date in dbt: If you only need day-level granularity, cast to date type in your dbt model to remove the time component entirely (see the example above).
• Set the project query timezone: Set the query timezone in Settings > Project Settings to match the timezone your data is stored in. See Project query timezone.
• Set LIGHTDASH_QUERY_TIMEZONE: Set LIGHTDASH_QUERY_TIMEZONE to match the timezone your data is stored in. Available for self-hosted instances, or contact us for Lightdash Cloud (Pro/Enterprise).

For non-UTC NTZ timestamps on BigQuery and Athena, see Handle ntz timestamps and timestamps with a non-UTC timezone correctly (#7010) - upvote or comment if this affects you.

Timestamps are stored in UTC but you want to view them in a local timezone

If your data is stored in UTC, the simplest path is to set the project query timezone to your preferred zone - chart axes, tooltips, table cells, and exports will all render in that zone, and DATE_TRUNC/EXTRACT intervals will bucket on its calendar boundaries.

If you only want to convert a specific column (rather than the whole project), you can use additional dimensions to create timezone-converted versions of a timestamp:

dbt v1.9 and earlier

columns:
  - name: created_at
    description: 'Timestamp in UTC'
    meta:
      dimension:
        label: 'Created (UTC)'
        type: timestamp
      additional_dimensions:
        created_at_est:
          type: timestamp
          label: 'Created (EST)'
          description: 'Created timestamp converted to Eastern Time'
          sql: "convert_timezone('UTC', 'America/New_York', ${TABLE}.created_at)"

dbt v1.10+

columns:
  - name: created_at
    description: 'Timestamp in UTC'
    config:
      meta:
        dimension:
          label: 'Created (UTC)'
          type: timestamp
        additional_dimensions:
          created_at_est:
            type: timestamp
            label: 'Created (EST)'
            description: 'Created timestamp converted to Eastern Time'
            sql: "convert_timezone('UTC', 'America/New_York', ${TABLE}.created_at)"

Lightdash YAML

dimensions:
  - name: created_at
    description: 'Timestamp in UTC'
    label: 'Created (UTC)'
    type: timestamp
  - name: created_at_est
    type: timestamp
    label: 'Created (EST)'
    description: 'Created timestamp converted to Eastern Time'
    sql: "convert_timezone('UTC', 'America/New_York', ${TABLE}.created_at)"

The pre-converted column is now in Eastern Time, but the project timezone will still try to apply its own shift on top. To prevent double-conversion, set convert_timezone: false on the additional dimension - see Per-dimension display opt-out.

Filters applied to a convert_timezone: false column still bind to project-timezone midnights, so absolute filters may behave surprisingly. If you need both timezone-correct display and timezone-correct filtering, do the conversion in your dbt model and use type: date if day-level granularity is sufficient.

Scheduled deliveries run at the wrong time

If your scheduled delivery is running at an unexpected time, check both:

1. The project-level default timezone in Project Settings > Syncs & Scheduled Deliveries
2. Any per-delivery timezone override on the individual scheduled delivery

The delivery timezone only controls when the delivery runs - the query results themselves use the query timezone hierarchy for date filter calculations.

Summary of workarounds

Scenario	Workaround	Limitation
”Today” shows wrong data	Set project query timezone in UI (admin)	Per-project, not per-user
”Today” shows wrong data	Use the per-chart timezone picker	Applies to one chart only
”Today” shows wrong data	Set LIGHTDASH_QUERY_TIMEZONE env var	Server-wide, not per-user
”Today” shows wrong data	Cast to date type in dbt	Loses intraday granularity
Timestamps stored in a local timezone (NTZ)	Set the data timezone on the warehouse connection	Experimental; not available on BigQuery or Athena
Timestamps stored in a local timezone (NTZ)	Cast to date type in dbt	Loses intraday granularity
Want to display data in a different timezone	Set the project query timezone	Applies to the whole project
Want to display data in a different timezone	Use additional dimensions with convert_timezone() plus convert_timezone: false	Display only - doesn’t fix filter boundaries
Single column should keep raw warehouse value	Set convert_timezone: false on the dimension	Filters still bind to project-TZ midnights
Scheduled delivery runs at wrong time	Check project and per-delivery timezone settings	Only affects delivery timing, not query results