Client-side timezone annotation versus server-side UTC normalization for Sentry event timestamps

Trade-off: Preserving regional context vs relying on server normalization

Sentry SDKs capture event timestamps in UTC by default (ISO 8601/RFC 3339), and the server-side processing pipeline normalizes all incoming timestamps to UTC before storage. However, the server assumes all timestamps arrive in UTC unless explicitly marked otherwise. This creates a design decision for distributed systems operating across multiple time zones.

Approach A: Annotate timestamps client-side with timezone metadata

Attach explicit timezone offsets or IANA timezone identifiers to each event payload before sending. This preserves the original regional context for debugging and correlation with local logs, but requires custom integration work since standard SDKs don't expose timezone annotation fields in the public API.

Approach B: Trust server-side UTC normalization exclusively

Send only UTC timestamps from all clients and perform timezone conversion at query or display time in the Sentry UI. This avoids custom payload modifications and works with standard SDK behavior, but loses the original local-time context that can be critical for reproducing time-sensitive issues like cron jobs or business-hour alerts.

Both approaches are documented as viable in Sentry's event payload specification, but the SDKs provide no built-in mechanism for Approach A, and Approach B's display-time conversion depends on UI settings that may not be consistent across team members.

• Which approach better supports incident correlation when services span multiple regions with different DST rules?
• Does the lack of SDK-level timezone annotation fields make Approach A impractical for teams without dedicated Sentry integration maintenance?