Why Daily Totals and Timestamps Shift Between Analytics Tools (Timezones Explained)

Short answer: a "day" in a report is a 24-hour window in some timezone. If two tools use different timezones, events near midnight fall on different dates, so daily totals differ even though the weekly total matches. Separately, a timestamp stored without a timezone marker can be displayed several hours off, which is a bug we shipped and fixed ourselves.

Table of Contents

1. How a Timezone Moves the Day Boundary
2. The Three Timezones in Every Report
3. The Bug We Found in Our Own Dashboard
4. Symptoms of a Timezone Problem
5. How to Make Reports Line Up
6. Advice for Developers
7. Key Takeaways

How a Timezone Moves the Day Boundary

Suppose an order is placed at 11:30 at night in India. In a tool reporting in Indian Standard Time, that is Tuesday. In a tool reporting in UTC, it is 6:00 in the evening on Tuesday, still Tuesday. But an order at 2:00 in the morning on Wednesday in India is 8:30 on Tuesday evening in UTC.

So the UTC tool gives Tuesday some of India's Wednesday morning, and both tools are correct. For a business whose customers are active late in the evening or early in the morning, the difference per day can be substantial.

The Three Timezones in Every Report

Problems come from assuming these are the same. A team in Bengaluru and a colleague in London can look at the same session and see different clock times, both correct for the viewer.

The Bug We Found in Our Own Dashboard

We store timestamps in UTC, which is standard practice. Our API returned them in a common text format but without the marker that says "this is UTC". A value looked like this:

2026-07-31T09:03:43.574174

A correctly marked UTC timestamp ends in Z:

2026-07-31T09:03:43.574174Z

That one character matters. JavaScript reads a date-time with no zone marker as local time. So every browser interpreted our UTC value as if it were already in the viewer's timezone, and then displayed it unchanged.

For a viewer in India, five and a half hours ahead of UTC, every session clock was five and a half hours early. A session that took place at 5:53 in the evening was shown as 12:23 in the afternoon.

Two things made this hard to notice:

• The wrong times looked plausible. Nothing was obviously broken. An afternoon session shown at lunchtime does not raise an alarm.
• Nothing at the point of use hinted at it. The code that displayed the time was correct for the input it believed it had.

We confirmed it by comparing the live response with a known event, then fixed it by parsing every API timestamp through one function that treats a value with no zone marker as UTC. We fixed it in the reader rather than changing the API format, because changing the format would have touched every response in the platform.

The general lesson: a timestamp without a timezone is not a point in time. It is a guess waiting to happen.

Symptoms of a Timezone Problem

• Daily totals differ between tools while weekly totals match.
• A campaign appears to start a day early or late.
• Session times are off by a consistent number of hours.
• The offset is a recognisable figure: 5:30 for India, or a whole number of hours elsewhere.
• Numbers shift by an hour twice a year, around daylight saving changes.
• "Today" shows partial data at different times for different people.

A consistent offset equal to your distance from UTC is nearly always a timezone issue rather than missing data.

How to Make Reports Line Up

1. Find each tool's reporting timezone. It is usually an account or property setting.
2. Set them all to the same one, normally the timezone your business operates in.
3. Check your ad and commerce platforms, which often default to the account creator's location.
4. Compare weekly totals first. If weeks match and days do not, you have confirmed the cause.
5. Write the reporting timezone on shared dashboards.
6. Use full days. Comparing "today so far" across tools adds refresh delays to the confusion.

Advice for Developers

• Store timestamps in UTC.
• Always serialise with an explicit zone marker.
• Parse through one shared function rather than calling the date constructor on raw strings in many places.
• Convert to local time only at display.
• Test with a machine set to a timezone that is not UTC and not a whole number of hours offset.

Key Takeaways

• A report's "day" depends on its timezone.
• Storage, reporting, and display timezones are three separate things.
• A timestamp with no zone marker will eventually be misread.
• Align reporting timezones and compare weekly totals to confirm.

Conclusion

Timezone problems are dull and common, and they make correct data look wrong. Ten minutes aligning settings saves hours of doubting your numbers.

Start free with DeepSync.