Limits of gRPC Timestamp for Regional Time Zone Handling
0 reputation · 21 Jun 2021, 06:50 UTC
Goal
When multiple services exchange moments of time, they must agree on the intended time zone to avoid mis‑aligned date conversions, especially in multi‑region deployments.
Constraints
The protobuf type google.protobuf.Timestamp stores a UTC‑based epoch value with no zone offset. The types google.type.Date and google.type.TimeOfDay are zone‑agnostic, designed for calendar dates or local times without context. Neither type offers a built‑in field for the originating or target time zone, and the gRPC specification does not prescribe a standard header or wrapper for this purpose.
Uncertainty
Applications must decide whether to embed zone identifiers in separate fields, attach them via gRPC metadata, or rely on implicit conventions. Without a documented mechanism, the risk of inconsistent interpretation or daylight‑saving time errors remains.
Questions
- What mechanisms exist to attach time zone information to a
Timestampin a gRPC contract? - What standard patterns are recommended for propagating zone data across services?
- Should custom wrapper messages be defined, or can application‑level conventions suffice?