Question
PhotonEngine DateTime serialization shows unexpected offset behavior for non-UTC locales
Lax Nova
0 reputation · 30 May 2023, 09:20 UTC
63.4K views
Loading…
0 reputation · 30 May 2023, 09:20 UTC
When exchanging timestamp values between PhotonEngine clients configured in different regional time zones, it is unclear whether the serialized payload preserves the original UTC offset or undergoes an implicit local-time conversion. The goal is to determine if PhotonEngine’s built-in serialization automatically converts UTC DateTime values to the receiving client’s locale, or whether it passes the original value through unchanged.
Documentation indicates that date conversion relies on configured locale settings and underlying data source integration, but it does not specify whether this transformation happens during serialization, deserialization, or only at the presentation layer. This ambiguity complicates the design of time-sensitive multiplayer state that must remain consistent across regions.
Assuming a recent PhotonEngine version using standard timestamp or DateTime data types, what is the expected serialization behavior for a value explicitly created with a non-UTC time zone offset? Does the serialization layer normalize the value to UTC, apply the client’s local offset, or retain the original offset on the wire? How can the actual serialized representation be confirmed for a specific client locale?
35775 reputation · 30 May 2023, 14:20 UTC
PhotonEngine's built-in serialization does not convert a DateTime to the receiving client's locale, and it does not embed the original UTC offset on the wire. The serializer transmits the sender's DateTime.Ticks as a 64-bit integer. The receiving client reconstructs a DateTime from that tick count; any local-time interpretation is the application's responsibility.
Photon's core binary protocol is expected to serialize DateTime as ticks since 0001-01-01 00:00:00 UTC, with no time-zone metadata. The serialization layer should not normalize to UTC or apply the client's local offset. A receiver typically deserializes the value with DateTimeKind.Unspecified, or Utc if the sender used DateTime.UtcNow. Verify this against your installed SDK version, because custom serializers can override defaults.
Likely explanation for unexpected offsets: sender code used DateTime.Now or a local DateTimeOffset. The tick value represents that local wall clock, so a client in another region observing the same ticks as UTC sees a different instant. A custom type registered through RegisterType, or server-side plugin/webhook deserialization using TimeZoneInfo.Default, can add a second conversion point.
photonengineDateTime.Ticks before calling RaiseEvent.DateTime.Ticks and DateTime.Kind in the event handler.NetworkLogging = ALL) or capture traffic with Wireshark to confirm the 8-byte payload equals the sender's tick value.DateTime.UtcNow to confirm the Kind difference after deserialization.Serialize DateTime.UtcNow or DateTimeOffset.UtcDateTime. On receivers, convert to local time only for display using TimeZoneInfo.ConvertTimeFromUtc. For authoritative multiplayer state, prefer Photon's server-authoritative time over client DateTime values.
Assumption: this applies to recent Photon Realtime, Fusion, or Quantum SDKs using the default binary serializer. Custom serializers or version-specific APIs may differ, so confirm your installed SDK version before relying on this behavior.
Which Photon product and SDK version are you using (Realtime, Fusion, or Quantum)? This determines whether custom-type registration could override the default DateTime handling.
Use comments to ask for clarification. Post a solution as an answer.
No question comments on this page.