How Timezone Errors Distort SaaS Revenue Reports

Your MRR report shows a $1,200 jump on February 1st that does not correspond to any new customers, expansions, or reactivations. You dig into the data. Twelve subscription renewals are showing up in February that should be January renewals. They happened on January 31st at 10:00 PM Eastern Time — which is February 1st at 3:00 AM UTC.

Your calculation used Eastern Time for month boundaries. Stripe used UTC. The result is twelve transactions permanently attributed to the wrong month in your historical data.

This is a timezone error — one of the most insidious calculation problems in SaaS revenue reporting because it is invisible until you look closely, and because it creates systematic distortions at every single month boundary in your entire reporting history.

This guide explains exactly how timezone errors enter revenue calculations, what they do to MRR and NRR, and how to fix them permanently.

How Stripe Handles Timestamps

Stripe stores every timestamp as a Unix timestamp — the number of seconds since January 1, 1970, 00:00:00 UTC. This is timezone-agnostic at the storage level, but it means that all Stripe timestamps are inherently UTC when converted to human-readable dates and times.

When you query the Stripe API and receive a timestamp like created: 1706745600, that converts to February 1, 2024 at 00:00:00 UTC. If you display that timestamp in New York (UTC-5), it shows as January 31, 2024 at 19:00:00 EST. Same moment in time, different calendar date depending on timezone.

This is not a Stripe flaw — Unix timestamps are a standard and correct way to store time. The problem arises when revenue calculations convert these UTC timestamps to a local timezone before grouping transactions by month, creating a systematic offset at every month boundary.

Where Timezone Errors Enter Calculations

Timezone errors typically enter revenue calculations at three points:

1. Month boundary definition

When a calculation defines "January" as January 1st 00:00:00 to January 31st 23:59:59 in a local timezone, any transaction that falls within those local-time boundaries is counted in January — even if the UTC timestamp puts it in February, or excludes UTC-January transactions that fall in December local time.

2. Data export and spreadsheet analysis

When you export Stripe data to a CSV or spreadsheet, many export tools automatically convert UTC timestamps to the local system timezone. If you then group transactions by month using the spreadsheet date column, you are grouping by local-time dates rather than UTC dates.

3. Dashboard timezone settings

Some analytics tools allow you to set a "reporting timezone" that converts Stripe's UTC timestamps before displaying data. If your reporting timezone is set to anything other than UTC, month-boundary transactions will be in different periods than Stripe's own data.

The Size of the Distortion

The magnitude of timezone distortion depends on two factors: how far your timezone is from UTC, and how many subscription events happen near month boundaries.

For a business processing subscription renewals continuously:

For a medium-sized SaaS business at UTC-5 (US Eastern), approximately 28 transactions per month boundary are attributed to the wrong period. At an average subscription value of $100/month, this represents $2,800 of MRR permanently in the wrong month — a $2,800 artificial MRR spike at the start of each month that cancels out at the end, creating constant noise in month-to-month comparisons.

Impact on MRR

Timezone errors create two types of MRR distortion:

Month-boundary spikes and dips

At the start of each month, transactions from the last few hours of the previous UTC month appear in the current local-time month. At the end of each month, transactions from the first few hours of the next UTC month are pulled into the current local-time month.

The net effect is artificial MRR fluctuation at month boundaries that is not driven by any business event. Month-over-month growth comparisons become noisy because each month inherits and sheds transactions at its edges due to timezone offset.

Systematic period mismatch

For businesses in timezones significantly ahead of UTC (UTC+5 to UTC+12), the timezone error can be large enough to affect daily revenue tracking. A subscription renewing at 8:00 PM UTC+8 appears as next-day revenue in UTC — shifting it across a day boundary. At scale, this creates systematic differences between local-time revenue tracking and UTC-based tracking that compound over time.

Impact on NRR, GRR, and Cohorts

Timezone errors are especially damaging to cohort-based metrics because they misassign customers to cohorts.

NRR and GRR are calculated by comparing a cohort's ending MRR to its starting MRR. Cohorts are typically defined by the month a customer's first subscription was created. If a subscription created at 11:00 PM UTC on January 31st is assigned to February cohort (because local time is February 1st), that customer's entire history is attributed to the February cohort instead of January.

This creates:

• January cohort slightly understated — missing boundary customers
• February cohort slightly overstated — including customers who started in UTC-January
• NRR calculations for both cohorts are wrong — the numerator and denominator include different customers than intended

For businesses with many customers in timezones far from UTC (particularly Asia-Pacific regions where UTC+8 to UTC+12 means significant daily offsets), cohort misassignment can be material — enough to affect NRR by 1-2 percentage points if not corrected.

How to Fix Timezone Errors

Rule 1: Always use UTC for all calculations

Define month boundaries in UTC. January is January 1st 00:00:00 UTC to January 31st 23:59:59 UTC. Never convert Stripe timestamps to local time before grouping by period.

Rule 2: Never mix UTC and local timestamps in the same dataset

If any part of your data pipeline converts timestamps to local time, all subsequent calculations will have timezone errors. Audit every step of your data flow and ensure UTC is preserved throughout.

Rule 3: Check your export tool's timezone handling

Many CSV export tools automatically convert UTC timestamps to the system's local timezone. When exporting Stripe data, look for an option to export in UTC or as Unix timestamps, and convert in your analysis tool rather than in the export step.

Rule 4: Apply UTC retroactively to all historical data

Once you fix the timezone handling going forward, recalculate all historical periods using UTC timestamps. Otherwise you will have a permanent break in your reporting history at the point where the fix was applied, making trend analysis across that boundary unreliable.

Rule 5: Validate with Stripe's own UTC-based data

Stripe's dashboard displays data in UTC by default for most metrics. Cross-check your calculated MRR against Stripe's MRR for specific periods to verify timezone handling is consistent. Systematic differences between your calculation and Stripe's that appear at month boundaries indicate a timezone issue.

Daylight Saving Time Complications

Daylight saving time (DST) creates an additional complication for businesses in timezones that observe it. When clocks change, the offset between local time and UTC shifts — typically by one hour.

For revenue calculations this creates two specific problems:

• DST transition months have inconsistent UTC offsets. In March (when most Northern Hemisphere DST starts), the UTC offset for a US Eastern Time business changes from UTC-5 to UTC-4 mid-month. Any calculation that uses a consistent local-time offset for the entire month will be wrong for part of it.
• DST creates phantom gaps and duplicates. When clocks spring forward, one hour is skipped — transactions in that hour appear to jump from 1:59 AM to 3:00 AM. When clocks fall back, one hour is repeated — transactions in that hour appear twice in local time.

The solution to DST complications is the same as the general timezone solution: use UTC exclusively. UTC does not observe daylight saving time. UTC+0 is constant year-round. By using UTC, DST transitions become irrelevant to revenue calculations.

What Dnoise Shows You

Dnoise uses UTC timestamps exclusively throughout every calculation — month boundaries, cohort definitions, churn dates, and expansion events are all evaluated against UTC. This means timezone errors cannot enter the calculation regardless of where your business is located or what timezones your customers are in.

• UTC-based month boundaries. Every period in Dnoise is defined in UTC. A transaction at 11:00 PM UTC on January 31st is always in January, regardless of local time anywhere in the world.
• Consistent historical data. All historical periods are calculated with the same UTC-based logic — there is no break in reporting history and no period where a different timezone was used.
• No local timezone conversion. Stripe timestamps are never converted to local time before grouping or comparison. The UTC value is used directly throughout the calculation pipeline.
• DST-proof. Because UTC does not observe daylight saving time, DST transitions do not create gaps, duplicates, or offset errors in any Dnoise calculation.

See also: why Stripe overstates MRR — timezone errors are one of five systematic distortions covered in detail there. Related: Stripe subscription analytics guide and MRR in the Metrics Library.

Summary

• Stripe stores all timestamps in UTC. Revenue calculations that use local time at month boundaries misattribute transactions to the wrong period.
• For a medium-sized SaaS business (2,000 subscriptions) at UTC-5, approximately 28 transactions per month boundary are in the wrong period — creating $2,800+ in artificial MRR noise per month.
• NRR and GRR cohort calculations are affected because customers are assigned to the wrong cohort when their subscription creation falls near a month boundary in local time but in the previous month in UTC.
• The fix: use UTC exclusively throughout all calculations. Define month boundaries in UTC. Never convert Stripe timestamps to local time before grouping.
• Daylight saving time creates additional complications for businesses in DST-observing timezones — UTC eliminates this by using a constant offset year-round.

Frequently Asked Questions