Time zones and dates
Each Workspace has one Reporting time zone, UTC unless an Owner or Organization Admin changes it. Metric queries use it everywhere they run: Explore, dashboards and their schedules, Pages, and agents. It decides which day, week, or month a moment belongs to, and how time filters and time ranges are read. An order placed at 2026-08-31T20:00:00Z counts on August 31 in a UTC Workspace and on September 1 in an Asia/Seoul Workspace, where it is 05:00 the next morning.
SQL queries run exactly as written. The Reporting time zone does not change them, so convert time zones in the SQL itself when you need to.
Set the Reporting time zone
Section titled “Set the Reporting time zone”Workspace Owners and Organization Admins change the zone; other members can’t.
- Open Settings → General in the Workspace.
- Find Reporting time zone and choose a zone. Search by city, such as
Asia/SeoulorAmerica/New_York; the list shows each zone’s current offset from UTC.UTCis also in the list. - Confirm the change.
New results group days and filter times in the new zone. Existing results keep the zone they ran with, so an older Explore run or dashboard entry is not rewritten. To see a dashboard in the new zone, choose Run again or Change inputs. The list contains current city names only; older aliases such as US/Eastern or Asia/Calcutta are not offered.
Agents can read the Reporting time zone but cannot change it. Read workspace/access with monomer_read ({"workspaceId":"…","path":"workspace/access"}); its reportingTimeZone is an IANA name such as UTC or Asia/Seoul. Ask your agent to state the zone when it reports a result grouped by day, week, or month.
After the zone changes, a dashboard Session refresh can return REFRESH_QUERY_RUN_UNAVAILABLE because earlier runs no longer match. Resolve the inputs first, then refresh.
How times are grouped
Section titled “How times are grouped”A time field in a semantic model holds one of three kinds of values:
| Kind | Meaning | How queries use it |
|---|---|---|
| Date | A calendar date | As stored |
| Local time | A wall-clock time with no time zone | As stored; it is read as a time in the Reporting time zone |
| Instant | An absolute moment, such as a timestamp with time zone or a BigQuery TIMESTAMP | Converted to the Reporting time zone first, then grouped |
Monomer usually infers the kind from the column’s warehouse type. Calculated fields, and columns without a time zone that store UTC times, need it declared; see Time fields and time zones.
Weeks start on Monday. A week is labeled by its Monday, so the week containing Saturday, August 1, 2026 is 2026-07-27. This holds on every warehouse, whatever a Snowflake account’s WEEK_START setting is.
What results contain
Section titled “What results contain”| Grain | Value | Example |
|---|---|---|
| Day, week, month, quarter, year | A date in the Reporting time zone | 2026-08-03 |
| Hour and finer | The Reporting time zone’s wall-clock time, without an offset | 2026-08-03T14:00:00.000000 |
Downloads, agent results, and dashboard chart and table code receive these values as text. Explore formats them for reading, such as Aug 3, 2026, and shows the raw value on hover. When a metric result groups or filters by time, Explore also names the zone, such as Times in Asia/Seoul. A result keeps the zone it ran with. Agent reads of a metric result include the zone as reportingTimeZone; it is null for SQL results.
Chart and table code must not parse them with new Date(); see Write a dashboard chart source and Format dashboard table cells.
Filters and time ranges
Section titled “Filters and time ranges”A time field’s filter type follows the grain the model defines for it. A field defined at day or coarser grain takes Date filters, such as 2026-08-01, which compare calendar days in the Reporting time zone. A field defined at hour or finer grain takes Timestamp filters. Other filter types are rejected before a run starts.
A Timestamp value names a moment with its offset, such as 2026-08-01T00:00:00+09:00 or 2026-07-31T15:00:00Z. Monomer converts it to the Reporting time zone’s wall-clock time and compares wall-clock times. In an Asia/Seoul Workspace, those two values are the same boundary.
The Time range reads its endpoints the same way: Date endpoints are days in the Reporting time zone, and Timestamp endpoints are converted to its wall-clock time. Monomer then widens the range to whole periods of the query’s grain.
Dashboard TIMESTAMP Parameters and Variables, including a schedule’s scheduled time, stay UTC instants and are converted when the query runs. A schedule’s own time zone decides when it runs and which days a CALENDAR_RANGE covers; the Reporting time zone decides how results group days. Use the same zone for both when a schedule reports whole days.
A filter saved in a metric definition keeps its SQL text. A time literal inside it means a wall-clock time in the Reporting time zone.
Known limitations
Section titled “Known limitations”- The repeated hour at the end of daylight saving time. For an instant field defined at hour or finer grain, Monomer keeps only the wall-clock time. On the day daylight saving time ends, the same wall-clock hour happens twice: in
America/New_Yorkon November 1, 2026,05:45Zbecomes 01:45 and06:15Zbecomes 01:15. Hourly groups combine the two moments, filters compare their wall-clock times, and a conversion metric can miss a later step inside that hour. Only rows in those two hours are affected. Fields defined at day or coarser grain are not affected. - BigQuery partition filters. On a table partitioned by a
TIMESTAMPcolumn, a time field defined at day or coarser grain still limits the partitions BigQuery reads. A field defined at hour or finer grain does not, so a table that requires a partition filter rejects the query. Filter the partition with a field defined at day grain. - Times stored in another zone without a time zone. Convert them in the field’s expression and declare the field as an instant; see Time fields and time zones.