How the Event Store uses timezones

When events are stored in the Event Store, the event timestamp is used to determine the event’s calendar day.

That calendar day is calculated by using the tenant timezone.

For example, the same event can belong to different calendar days depending on the timezone that is used:

The Event Store uses this calendar day information for:

• Data organization and partitioning
• Query performance
• Reporting and dashboard aggregation
• Replay and export operations

As a result, timezone changes can influence how data is grouped and retrieved.

What happens when the tenant timezone changes

• Historical data is not rewritten: Events that were already stored before the timezone change remain organized according to the timezone that was active when they were ingested. New events are stored by using the new timezone. This means historical and future data can be organized by using different day boundaries.

• Future events can be assigned to different days: After the timezone change, events occurring near midnight can be assigned to a different calendar day than they would have been previously. This primarily affects:

  • Daily reporting
  • Monthly reporting
  • Data exports
  • Replay operations

Impact on reporting and dashboards

After a timezone change, dashboards and reports use the current tenant timezone when calculating daily and monthly totals.

As a result:

• Historical events near day boundaries can appear under different dates.
• Daily counts can shift between adjacent days.
• Monthly totals near month boundaries can move between months.
• Trend charts can look different before and after the change.

This behavior reflects a change in time bucketing rather than data loss.

For example, an event originally counted on May 31 can later appear under June 1 if the new timezone places that event on a different side of the day boundary.

Impact on replay and export operations

Replay and export operations often rely on date ranges.

After a timezone change:

• Events near day boundaries can fall into different date ranges.
• A replay can unintentionally exclude some records.
• A replay can include records from an adjacent day.

This risk is greatest for data occurring around:

• Midnight
• Month-end
• Billing period boundaries

Organizations should carefully validate replay and export ranges around the timezone change date.

What is not affected

A timezone change does not affect:

• Total event counts
• Event uniqueness or deduplication logic
• Event identifiers
• Previously processed billing records
• System operational timestamps

The underlying events remain intact. The primary impact is how events are grouped into days and reporting periods.

Best practices

• Treat the tenant timezone as a long-term setting: Whenever possible, establish the correct timezone before onboarding production data. Frequent timezone changes are not recommended.

• Review reporting around the change date: Expect historical daily and monthly reports to shift slightly for events occurring near timezone boundaries. This is expected behavior and does not indicate missing data.

• Treat timezone changes in production as a controlled operational change: For production environments with existing Event Store data, treat a tenant timezone change as a controlled operational change. Before and after the update, validate downstream processes that rely on Event Store data, including reporting, replay, export, and reconciliation workflows.

• Consider reprocessing historical data if consistency is required: Organizations that require all historical data to align with the new timezone can choose to reprocess or backfill affected data so that historical and future records follow the same timezone convention. Consult Zuora Support before planning a large-scale reprocessing effort.

• Prefer explicit timezone information in event data: When possible, provide event timestamps that include timezone or UTC offset information. This ensures the event represents an unambiguous point in time and reduces the risk of interpretation differences during ingestion.

• Plan timezone changes carefully: If a timezone change is required:

  • Identify the effective change date.
  • Notify reporting and billing stakeholders.
  • Review any dashboards that rely on daily or monthly aggregations.
  • Validate replay and export procedures.
  • Evaluate the impact on reconciliation processes that rely on date-based grouping or reporting.

• Validate replay and export jobs: For any replay or export that spans the timezone change period:

  • Verify date ranges carefully.
  • Review record counts before and after processing.
  • Pay special attention to month-end and billing-period boundaries.