How dates and time zones are handled
MarqIQ stores every timestamp as an instant and decides which calendar day it belongs to when a report runs. Which calendar it uses is not the same on every screen, and that is the whole reason two reports can disagree about the same evening. This article is the exact rules; if two screens already disagree and you want the general causes, read Two screens show different numbers for the same thing.
The workspace time zone
One time zone applies to the whole workspace. It is not a per-person setting and not a per-report setting.
| Where it is set | Account & Team → Account settings in the sidebar, in the Region & Timezone card, under Timezone |
| Who can change it | Workspace admins. Anybody else saving that page gets “Only workspace admins can change organization settings.” |
| Default | UTC |
| Choices | 17 zones: UTC, New York, Chicago, Denver, Los Angeles, São Paulo, London, Paris, Berlin, Moscow, Dubai, Kolkata, Singapore, Tokyo, Shanghai, Sydney and Auckland. There is no free-text field, so a zone outside this list cannot be chosen |
| Effect of changing it | Reports re-bucket the next time they run. No stored timestamp is altered, so nothing is lost and nothing is converted twice |
Note
Each zone carries its own daylight-saving rules, so a spring day is 23 hours long and an autumn day 25 in the zones that observe it. MarqIQ reads the zone’s real rules rather than a fixed offset, so those days are bucketed correctly and a total for that week counts every submission once.
Where the workspace time zone applies, and where it does not
This is the table to read before you compare any two numbers.
| Screen or control | Cut on |
|---|---|
| Year, Quarter and Month dimensions in the report builder | Your workspace time zone |
| The same dimensions on a dashboard tile | Your workspace time zone |
| The daily trend on the prebuilt analytics overview and the funnel | Your workspace time zone |
| The daily buckets on the influence report | Your workspace time zone |
| The Created range on a tool’s Data Audit and Executive Read | The UTC calendar, whatever your workspace time zone is |
| The monthly bars on the attribution report | The UTC calendar, whatever your workspace time zone is |
| A period in an Ask question, on the created date or on the close date | The UTC calendar, whatever your workspace time zone is. For won and lost deals in HubSpot, Pipedrive and Pardot, and for the people and companies on them, a line under the answer says how many of the deals fall outside the period in your workspace time zone, and how many come into it |
| The 30d, 90d, 6mo, 1yr and 3yr buttons in the report builder | Neither — a rolling count of 24-hour periods back from the moment the report ran |
| The Last 30 days, Last 90 days and Last year list on a dashboard | Neither — the same rolling count |
So which day is an 11pm touch on?
A submission at 11pm on 30 September in Los Angeles is stored as 6am on 1 October UTC. In a workspace set to Los Angeles it falls in September’s Month bucket in the report builder, and in October on the Data Audit Created range and on the attribution report’s monthly bars. Both are behaving as designed. Neither is a rounding error, and neither can be configured away, so a September figure from one screen and a September figure from the other are not the same population.
Which timestamp each source buckets on
The Year, Quarter and Month dimensions read one timestamp per record, and it is not the same field on every source. This is the commonest reason a “by month” report does not look like the same question asked in your tool.
| Source | Timestamp read | What that means |
|---|---|---|
| Marqiq Attribution | The submission time | A form fill is counted in the month it was filled in |
| A connected tool, or an imported spreadsheet | Last activity, falling back to created date where there is no last activity | A record created in January and touched in June counts in June. Grouping by Month on a CRM source is not a report of when records were created |
| Unified (Cross-System) | That person’s earliest form submission; where they have none, a CRM record’s last activity or created date | One date per person, not one per record |
Tip
To group a CRM source by when records were created, add a filter on that tool’s own created-date field rather than using Month. The filter compares the value the tool stores, so it answers the question your tool would answer.
Created date against close date
Nothing in the report builder buckets on a close date. Where a report needs deals by the month they closed — a bookings report, for instance — build it on the tool’s own close-date field as a dimension, or read the Last twelve months chart on that tool’s Executive Read, which counts creations and wins on their own separate dates and says so. Ask reads a period on the close date when the question is about deals that were won, lost or closed: “won revenue by month in 2025” is the money won in each month, by the month each deal closed. It does the same for the people and companies on those deals: “leads we lost last month” are the people on a deal lost last month, whenever they were created. Read Ask a question about your records for which questions use which date.
Bucket boundaries
| Bucket | Runs from | Notes |
|---|---|---|
| Month | The 1st to the last day, in the workspace time zone | A report builder dimension. Written as YYYY-MM |
| Quarter | Calendar quarters — Q1 is January to March | A report builder dimension. Written as YYYY-Qn. There is no fiscal-year setting, so a business whose year starts in April cannot make Q1 mean April to June |
| Year | January to December | A report builder dimension. Calendar years only |
| Day | Midnight to midnight in the workspace time zone | Not a report builder dimension. Days are bucketed by the daily trend on the prebuilt analytics overview, by the funnel and by the influence report, where they are written as YYYY-MM-DD |
| Week | Not available | There is no week dimension and no day dimension in the report builder, so a weekly figure cannot be rolled up from builder rows. Group by Month, or read the daily trend on the prebuilt analytics overview |
The report builder offers exactly three time dimensions: Year, Quarter and Month.
A month grouping does not come out in date order
Rows are ordered by the first measure in Values, largest first, and the chart is drawn in the same order as the table. Group submissions by Month and your busiest month is the top row and the leftmost bar, not January. Nothing in the builder sorts a dimension by its own value. Where the order matters, read the figures out of the table and put them in date order yourself, or read the daily trend on the prebuilt analytics overview, which is drawn in date order.
The *Created* range on a tool’s audit pages
The preset pills on a tool’s Data Audit and Executive Read resolve against the UTC calendar, and both ends are inclusive: a range ending 30 September includes everything up to the last millisecond of 30 September UTC.
| Pill | The range it resolves to |
|---|---|
| All time | No bounds at either end |
| Last 30 days | Today and the 29 days before it — 30 days inclusive |
| Last 90 days | Today and the 89 days before it — 90 days inclusive |
| This quarter | The first day of the current calendar quarter, to today |
| Last quarter | The whole previous calendar quarter, first day to last day |
| This year | 1 January to today |
| Last 12 months | The day after this date last year, to today — 365 days inclusive, or 366 when a 29 February falls inside it |
| Custom | The two dates you type, both ends inclusive |
- A custom range typed backwards is turned round rather than refused, so a from later than its to gives you the range between the two dates.
- A date that is not a real calendar day is dropped, and that end of the range becomes unbounded rather than being guessed at.
- The range travels in the address bar, so a filtered view pasted to a colleague shows them the same dates.
- Ranges are written out as “1 Jul 2026 – 30 Sep 2026”, or “from 1 Jul 2026” and “up to 30 Sep 2026” when only one end is set. Month names are always the fixed three-letter English forms, so the label reads the same for everybody.
The rolling day counts in the report builder
The buttons in the builder and the list on a dashboard are not calendar ranges. Each one subtracts that many 24-hour periods from the moment the report runs, so the boundary moves through the day as you work and does not land on midnight in any zone.
- The builder offers 30d, 90d, 6mo (180 days), 1yr (365 days) and 3yr (1,095 days), and opens on 90d.
- A dashboard offers Report default, Last 30 days, Last 90 days and Last year.
- They filter Marqiq Attribution only. On a connected tool, an imported spreadsheet or Unified (Cross-System), every record inside the row cap is read whichever button is lit.
- Run the same report twice an hour apart and the boundary has moved an hour. Two people reading it at different times of day are not reading quite the same set.
Making two reports comparable on purpose
Decide which calendar the answer belongs to before you build anything.
A board figure usually wants calendar months in your own time zone. An operations figure usually wants the same cut as the tool the team works in.
Build both reports on the same source.
Two sources bucket on two different timestamps, so the same month means two different populations before any date setting is involved.
Use Month or Quarter rather than a rolling day count where the two will be compared.
A named month is the same for everybody who opens it. A rolling 90 days is not the same 90 days tomorrow.
Write the basis into the report’s name.
“Submissions by month — workspace time zone” and “Deals created 1 Jul – 30 Sep, UTC” cannot be mistaken for each other on a dashboard tile, where nothing else on screen says which is which.
Quote the date basis alongside any figure that leaves MarqIQ.
A month figure and a rolling-90-day figure put on the same slide will be read as comparable unless each one says what it is.
Next steps
Related articles
Was this article helpful?