Fix Timezone Mismatch Skewing Your Analytics Reports
Your 'today' shows yesterday's traffic? Fix the timezone mismatch.
It's early evening on a Tuesday and the dashboard says today's traffic is a fraction of yesterday's. Panic. Then you check the server logs and everything looks normal.
Often the culprit is a reporting timezone set to UTC while the team sits in San Francisco. By early evening Pacific time, "today" in UTC has already rolled over and is only an hour or two old. Classic timezone mismatch.
It's a sneaky one because nothing errors. Every morning standup just looks at numbers that don't line up and draws the wrong conclusion. If you're migrating from GA4 or setting up fresh, getting this right from day one saves you from exactly this headache.
What You'll Have at the End
By the end of this guide:
- Your project timezone set correctly — the actual IANA timezone, not a UTC offset
- Reports that reset at your local midnight
- DST transitions that just work
- Week boundaries that match your business calendar
If you're running conversion funnels or comparing day-over-day performance, this matters. A lot.
Prerequisites
- Admin access to your analytics dashboard
- Knowledge of your business's primary timezone
- Ten minutes. Maybe fifteen if you double-check things. (You should double-check things.)
Step 1: Find Your Current Timezone Setting
First, figure out what your dashboard thinks "today" means.
In your analytics tool, open the project or property settings and find the timezone option (labels vary between tools and releases, so look for "timezone" or "reporting"). You'll see one of three things:
- A named timezone like
America/Los_AngelesorEurope/London— good, this handles DST - A UTC offset like
UTC-08:00— bad, this breaks during DST transitions - UTC or blank — worst case, your data resets at midnight GMT regardless of where you are
In GA4, it's the Reporting time zone field in the property settings under Admin.
What you should see: A named IANA timezone matching your business location.
If you see a bare UTC offset or just "UTC," that's your problem. A team in New York using UTC-05:00 will be off by an hour from March to November when EST becomes EDT. Phantom traffic drops that turn out to be DST transitions eat hours of debugging. Hours.
Step 2: Pick the Right Timezone
Don't pick the offset. Pick the name.
| If your business is in... | Use this timezone |
|---|---|
| US West Coast | America/Los_Angeles |
| US East Coast | America/New_York |
| UK | Europe/London |
| Central Europe | Europe/Berlin |
| India | Asia/Kolkata |
| Australia East | Australia/Sydney |
| Japan | Asia/Tokyo |
The IANA timezone database handles DST automatically. Clocks spring forward in March? Reporting adjusts. Fall back in November? Same thing.
Why this matters: If you set UTC-08:00 instead of America/Los_Angeles, you're telling the system "always use this offset" — which is wrong for most of the year. A fixed offset set once and forgotten can leave year-over-year comparisons off by an hour for entire quarters until someone audits the data. Easy mistake. Easy to avoid.
Step 3: Update Your Project Settings
Change it on the same settings screen and pick the IANA name from the table above.
In GA4, open the same Reporting time zone field under Admin and select from the dropdown.
One caveat: Changing reporting timezone doesn't rewrite the stored events. They keep their UTC timestamps; the setting changes how they're grouped into days. Tools differ on what happens to older reports: some apply the new timezone only from the day you change it, others recalculate past days in the new timezone. Check which yours does before comparing numbers across the switch.
Either way, if you're mid-month and comparing "this week" to "last week," expect some weirdness around the change. It'll settle down. Give it a few days.
Step 4: Verify the Change Worked
After saving, check three things:
Check 1: Does "today" reset at your midnight?
Wait until after midnight your time, then check if yesterday's count is final and today's starts fresh. If you're impatient, check the hour-by-hour breakdown. The day should start at hour 0 in your timezone, not hour 0 UTC.
Check 2: Do week boundaries match your calendar?
Pull a weekly report. If your business runs Monday-Sunday weeks, the week should start Monday at midnight your time. Some tools default to Sunday. This is a separate setting from timezone — check it. (Sunday-start weeks are the wrong default for most businesses. Fight me.)
Check 3: Does your hour-of-day report make sense?
Look at your traffic by hour. Peak hours should align with when your users are actually awake. If you're a US business and your peak hour is 3am, something's still wrong. Either your timezone is off, or you've got a bot problem (which is a different guide — check out ClickzProtect if bots are hitting your affiliate or paid traffic).
Common Analytics Timezone Mismatch Errors and How to Fix Them
Today's count is higher than yesterday's final count
Cause: You changed timezone mid-day, and some of yesterday's late-night traffic (in the old timezone) got recategorized as today in the new timezone.
Fix: This corrects itself after 24 hours. The transition day is weird; days after are fine.
Daily totals look off after a DST change
Cause: You're using a fixed UTC offset instead of a named timezone.
Fix: Switch to the IANA name (e.g., America/Los_Angeles instead of UTC-08:00). The database handles DST automatically.
Year-over-year comparison shows a 1-hour shift
Cause: Same DST issue, but manifesting in comparisons. If you fixed it recently, last year's data was calculated with the wrong offset.
Fix: No perfect fix for historical data. Named timezones prevent this going forward. Some teams compare "same day of week" rather than "same date" to mask the shift. It's annoying, and there isn't a cleaner answer.
Teammates see different numbers for the same day
Cause: Some tools let users set personal dashboard timezones. If one person is viewing in UTC and another in local time, their "today" numbers won't match.
Fix: Standardize on a project timezone for official reporting. Personal views are fine for quick checks, but any number that gets shared should come from the same timezone setting.
Traffic looks like it dropped but revenue didn't
Cause: Your analytics tool and your payment processor use different timezones. Stripe's API timestamps are in UTC. If your analytics reports in local time, day boundaries don't align.
Fix: When correlating data across tools, convert everything to the same timezone first. Pull reports that cover complete days — midnight to midnight in one consistent timezone — rather than partial-day snapshots. Yeah, it's tedious. Cross-tool analytics is always tedious. If you're tracking phone conversions with a call platform such as VeloCalls, make sure call timestamps align with your analytics timezone too.
Edge Cases: When Timezones Get Weird
A few gotchas that bite even experienced teams:
Locations without DST: Arizona (except Navajo Nation) doesn't observe DST. America/Phoenix handles this. If you use America/Los_Angeles for an Arizona business, you'll be off by an hour in winter.
Multi-region businesses: If you have offices in New York and London, pick one as the "reporting timezone" for company metrics. Individual region reports can use local time, but the roll-up needs consistency. Anything else that reports by day, such as sprint dashboards or billing exports, should use the same timezone.
Server-side events: If you're using a backend SDK to track server-side events, make sure those timestamps are sent in UTC. The reporting layer handles conversion to local time. Don't convert on the client side before sending — that creates ambiguity when you have concurrent requests across timezone boundaries.
Historical DST changes: Some countries have changed their DST rules over time. The IANA database tracks this, so a timestamp from 2015 gets the 2015 rules applied. Fixed UTC offsets can't do this.
Why This Matters for Data Quality
Bad timezone settings don't just make your "today" look wrong. They compound.
Dashboards built on broken foundations train teams to distrust data. The marketing lead sees numbers that contradict her intuition? She stops checking the dashboard. CEO asks why Monday's traffic was low and the answer is "actually it wasn't, the timezone was wrong"? Credibility erodes. Fast.
It's easy to build an entire reporting setup on UTC-anchored data and only realize months later that every daily comparison was off by hours. The data was accurate at the event level. Every timestamp was correct. But the aggregation layer sliced it wrong.
Get this right early. One setting. Saves you from explaining timezone math to your CEO in a board meeting.
Next Steps
Once your timezone is configured:
- Review your uptime and alerting rules — verify that alert windows and quiet hours respect your timezone, not UTC
- Check your email reports — daily digests should arrive in your morning, not UTC morning. A 4am email usually means nobody changed the schedule timezone
- Check other tools that report by day — using JustEmails for transactional email? Compare any daily numbers from it in the same timezone as your analytics
Migrating from GA4? Check the timezone on the new project rather than assuming it matches the old property. Defaults vary between platforms.
Frequently Asked Questions
What is the difference between reporting timezone and collection timezone?
Collection timezone is when the event was recorded on the server (usually UTC). Reporting timezone is how that data gets displayed in your dashboard. If your reporting timezone is America/New_York but events are stored in UTC, a pageview at 11pm EST shows up as 4am UTC the next day — making "today" look wrong until you set reporting timezone correctly.
Why does my analytics 'today' show different numbers than yesterday's 'today'?
This happens when your reporting timezone doesn't match your business timezone. If the dashboard is set to UTC but your team works in PST, "today" resets at 4pm your time instead of midnight. Yesterday's "today" included a full day. Today's "today" only shows partial data until midnight UTC.
How does Daylight Saving Time affect analytics reporting?
DST shifts your UTC offset by one hour twice a year. If your timezone is set to a fixed UTC offset like UTC-5 instead of a named timezone like America/New_York, you'll be off by an hour for much of the year. Named timezones handle DST automatically. Fixed offsets don't.
Should I store analytics data in UTC or local time?
Always store in UTC. UTC is unambiguous — no DST shifts, no timezone confusion. Then convert to local time at report-render time using the user's or project's configured reporting timezone. Storing in local time creates permanent ambiguity around DST transitions.
Try JustAnalytics
All-in-one observability in one under-5KB script: cookieless analytics + error tracking + APM + session replay + uptime + structured logs. Replaces GA4 + Sentry + Datadog + Pingdom + LogRocket. Free tier (100K events/mo), Pro at $49/month ($39/month billed annually).
Author at JustAnalytics.