Timezones

How Lightdash handles timezones in date filters, 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 determines the timezone for relative date filter calculations 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. This timezone is used for all relative date filter calculations in that project, unless overridden by a per-chart timezone.

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

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.

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. This can cause date filter boundaries to not line up with your data.

Workarounds:

• 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).

Better support for non-UTC timestamps is being tracked in 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 but you want to display it in a specific timezone (e.g., Eastern Time), 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)"

This changes how the data is displayed but does not affect how relative date filters calculate “today.” Filters applied to the converted dimension will still use UTC boundaries. If you need both timezone-correct display and timezone-correct filtering, convert the timestamp in your dbt model and use type: date if day-level granularity is sufficient.

If you need time-level analysis (e.g., grouping by hour) in a non-UTC timezone, there is currently no built-in workaround. You can do the timezone conversion in your dbt model, but relative date filters will still calculate boundaries in UTC. This is a known limitation.

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 in local TZ, don’t want conversion	Set project query timezone to match	Per-project, not per-user
Timestamps in local TZ, don’t want conversion	Cast to date type in dbt	Loses intraday granularity
Want to display data in a different timezone	Use additional dimensions with convert_timezone()	Display only — doesn’t fix filter boundaries
Want timezone-correct filtering at hour level	No built-in workaround	Known limitation
Scheduled delivery runs at wrong time	Check project and per-delivery timezone settings	Only affects delivery timing, not query results