Filter — date_range

When to use date_range_preset

Use date_range_preset when the user picks a date range from a small set of named presets — last 30 days, this month, this quarter, year-to-date, etc. This is the right default for most operational dashboards: it gives users one click to switch period without typing dates.

Use date_range when the user must pick arbitrary endpoints. Use cutoff_date when the input is a single date instead of a range.

Required fields

id — unique within the dashboard's filters block.
type: date_range_preset

Optional fields

label — display label above the picker.
default — object selecting the preset to apply on first load: { preset: <id> }. Must reference an id from presets (or one of the built-ins if presets is omitted).
presets — array of { id } objects in the order they should appear in the picker. The id must be one of the built-in preset ids below; the schema rejects unknown ids at looky validate time.
bindings — object overriding the parameter names: { date_from: <param-name>, date_to: <param-name> }. Use this when the model expects parameter names other than the defaults date_from / date_to.

Built-in preset ids

All preset ids are computed in the picker's runtime. Authors do not declare from/to tokens — the picker resolves the id to a concrete {date_from, date_to} on each run, using the workspace timezone.

today — single day: today's date.
yesterday — single day: today minus one.
last_7_days, last_30_days, last_90_days — rolling N-day windows ending today (inclusive).
this_week, last_week — ISO week (Monday through Sunday).
this_month, last_month — calendar month.
this_quarter, last_quarter — calendar quarter (Jan-Mar, Apr-Jun, Jul-Sep, Oct-Dec).
this_year, last_year — calendar year.

Writing any other id is rejected by looky validate with a schema error pointing at the offending presets[i].id. If a preset you need isn't in the list, that's a request for a new built-in — not something authors patch in YAML.

How the value reaches the Malloy query

The picker resolves the selected preset id to a {date_from, date_to} pair using the workspace timezone.
Those values flow as the date_from and date_to parameters into every viz on the dashboard.
If bindings is set, the same values are also bound to the parameter names listed there.

The Malloy model declares the parameters and uses them in where: clauses, exactly like with the other date filters.

Adapter differences

Same date / timestamp caveat as cutoff_date — see the source adapter comparison for the Postgres / MySQL pattern.

Worked examples

Default to this year, with five presets in the picker:

filters:
  - id: period
    type: date_range_preset
    label: Period
    default:
      preset: this_year
    presets:
      - id: last_30_days
      - id: this_month
      - id: this_quarter
      - id: this_year
      - id: last_year

Bind to a custom parameter pair (the model uses start_date / end_date):

filters:
  - id: period
    type: date_range_preset
    label: Period
    default:
      preset: this_month
    bindings:
      date_from: start_date
      date_to: end_date

Two independent ranges in the same dashboard, each on its own parameters:

filters:
  - id: current_period
    type: date_range_preset
    label: Current
    default:
      preset: this_month
    bindings:
      date_from: current_from
      date_to: current_to
  - id: comparison_period
    type: date_range_preset
    label: Compare to
    default:
      preset: last_month
    bindings:
      date_from: compare_from
      date_to: compare_to

Common pitfalls

looky validate rejects a preset id. The id must be one of the built-ins. Typos like last_7_dys or invented ids like fiscal_q1 are rejected at push time so the dashboard never lands in prod with a silently-broken preset.
The default doesn't apply on first load. default.preset must exactly match an id from presets (or, if presets is omitted, one of the built-ins).
The query doesn't pick up the date range. The Malloy model must declare the parameters that the picker binds to — by default date_from / date_to, or the names in bindings if you set them.
Two date filters fight over date_from / date_to. If you have multiple date_range_preset filters on the same dashboard, set bindings on each to bind to distinct parameter names.

Filter — date_range_preset