The Account Time Zone: One Rule for Every Date in Qvasa

Every date range, chart bucket, preset and timestamp in Qvasa resolves in one zone: the account's Primary Time Zone, or the zone a date filter was saved with, which starts out as the same thing. This guide is the one place that rule is written down: what the setting is, exactly how each kind of date range uses it, what happens at daylight saving, which pages follow it outside dashboards, and the short list of things that deliberately run on a different clock.

The Setting

Settings → Primary Time Zone. An account admin picks it from a dropdown and clicks Update Timezone. It applies to the whole account, not to the person who set it, and new accounts start on UTC.

The choices are fixed offsets from UTC, from UTC-12 to UTC+11, not named regions like "America/Los_Angeles". That is deliberate: an offset is the same all year, so a day, a week or an hourly grid never gains or loses an hour. What it means for daylight saving is below.

The One Rule on Dashboards

Every date filter, on a widget or on a quick filters bar, has its own Adjust results based on a timezone dropdown. It defaults to the account's Primary Time Zone and is saved with the filter. Everything that filter produces is worked out in that zone:

Kind of range	How it resolves, in the filter's zone
Fixed dates (a start and end date)	From local midnight at the start of the first day to the end of the last day. A start or end hour, when you set one, is also read on that clock.
Rolling days ("last 7 days")	Whole clock days: from the start of the day seven days ago to the end of today. The comparison period is the seven whole days before that.
Rolling weeks and months	Calendar periods on that clock: weeks run Monday to Sunday, months from the 1st. "Last 2 weeks" starts on the Monday two weeks back.
Rolling hours and minutes	Whole clock hours or minutes: "last 1 hour" is the current partial hour plus the one before it. Offsets are whole hours, so the boundaries are the same in every zone.
Presets ("Today to date", "Yesterday", "Previous week", "Business week to date", "Month to date", "Previous quarter")	Resolved on that clock every time the widget loads: "Previous week" is the last full Monday-to-Sunday week in the filter's zone (the Thursday-to-Wednesday variants likewise), "Yesterday" is yesterday's local midnight to midnight.
Chart buckets	Day, week and month points follow the same calendar; hour and minute points are shifted so their labels read in the filter's zone.
Timestamps on widgets	Date columns in tables and the "at 09:12:30" stamp on a live widget are shown in the filter's zone.

Because the zone is saved with the filter, changing the account's Primary Time Zone does not move widgets that already exist. A widget keeps the zone it was saved with until someone opens its filter and picks another; the dropdown on a new filter starts from the new account zone.

Daylight Saving

A Qvasa zone is a fixed offset, so a Qvasa day is always 24 hours and its midnight never moves. Where your region observes daylight saving, the local wall clock moves instead. An account on UTC-8 lines up with the Pacific wall clock in winter; in summer, when the Pacific coast is at UTC-7, Qvasa's day starts at 01:00 on the office wall and "9 to 5" is 08:00 to 16:00 on the dashboard.

If you want dashboard days to follow the wall clock all year, change the Primary Time Zone when the clocks change (UTC-8 to UTC-7 in spring, back in autumn), and pick the new zone on the date filters you care about, since saved filters keep theirs.
If you want a stable grid that never shifts, which is what most reporting wants, leave it alone: every day on every chart is the same 24 hours, in summer and winter.
Business-hours metrics are the exception and follow the wall clock, below.

Outside Dashboards

Pages that are not dashboards use the Primary Time Zone directly: the ticket record page ("View in Qvasa"), the ticket timeline and call history, alert notification history, the WFM shift pages (the shift start label names the zone), and ticket status mapping dates.

What Runs on a Different Clock

Feature	Its clock	Why
Business-hours metrics (business-hours first touch, reply time, requester wait)	The Zendesk schedule's own zone, by name, with daylight saving. A schedule typed in by hand with an offset is measured on that fixed offset.	"09:00" must be 09:00 on the office wall in July and in January.
Zendesk API metrics for Talk (live queue, today's figures)	Zendesk's clock: "today" resets at midnight in your Zendesk account's time zone. The time on the widget is when Zendesk answered, shown in the account zone.	The number is fetched straight from Zendesk and is the same one its dashboard shows.
Alert and export schedules	UTC. Cron expressions are written in UTC and run against UTC time.	A schedule must be predictable all year; convert your local hours once.
Qualitative question backfill limits	The daily limit resets at midnight UTC.	A platform-wide quota.
Raw timestamps in alert payloads and webhooks	UTC, when you use the raw form of a timestamp variable; the formatted form is in the account zone.	A receiving system parses UTC.

For AI Agents and the API

The date filter's discovery endpoint returns the account's zone as account_primary_time_zone and the allowed values as timezone_dropdown_options.
Every strategy of filters_date_and_time (relative rolling, absolute fixed, the named presets) resolves in the account zone unless the filter carries its own timezone value, which is one of the same UTC±N strings.
Zendesk API metrics ignore the date filter entirely; the catalog says so on each one.

FAQ

Which zone is "Previous week" in? The zone of the date filter it sits on, which defaults to the account's Primary Time Zone: the last full Monday-to-Sunday week on that clock, resolved each time the widget loads.
Why does my day start at 01:00 in summer? The zone is a fixed offset and does not follow daylight saving. Change the setting with the clocks, or keep the stable grid; see Daylight Saving above.
I changed the account zone and nothing moved. Saved date filters keep the zone they were saved with. Open the filter and pick the new zone, or clear it and save again.
Does Zendesk's account time zone matter? Only for Zendesk API metrics and for business-hours schedules synced from Zendesk, which carry their own zone. Everything else uses Qvasa's setting.
Why are alert schedules in UTC when my dashboard is not? Schedules must fire at the same instant all year; the cron guide has recipes for local business hours.