Bevy–chrono timestamp strategy: UTC persistence vs zone-aware for multiplayer determinism

Answer the core question first

Persist every timestamp as chrono::DateTime (or an epoch integer) and store the user’s time‑zone only for UI. This guarantees that the same instant is written identically on every machine, so save files are portable and replays match across clients.

Why UTC is the safe choice

• Unambiguous instant: no DST or historical offset changes.
• Same representation on all clients, regardless of TZ env or OS settings.
• Deterministic: fixed‑step logic never calls Utc::now(), so gameplay state is identical.

Problems with zone‑aware persistence

• Two clients in different zones serialize the same instant differently (e.g., 2024‑10‑13T05:46:42+00:00 vs +02:00).
• Different chrono-tz database versions can change offsets, breaking hash‑based replay checks.
• Sorting or comparing mixed‑zone timestamps becomes error‑prone.

Impact on multiplayer deterministic replay

Deterministic replay relies on identical serialized state across all participants. If the saved timestamp includes a zone offset, two clients will have different binary blobs, causing diverging hash values even though the underlying event occurred at the same instant. Using UTC (or epoch) removes that source of variance.

Recommended Bevy resource pattern

use bevy::prelude::*;
use chrono::{DateTime, Utc};
use chrono_tz::Tz;

/// Holds the canonical time used for all persistent events.
#[derive(Resource, Serialize, Deserialize)]
struct UtcClock {
    epoch: DateTime,
}

/// User‑specific time‑zone preference used only for UI.
#[derive(Resource)]
struct UserTz {
    tz: Tz,
}

fn setup(mut commands: Commands) {
    // Capture the session start time once.
    commands.insert_resource(UtcClock { epoch: Utc::now() });
    // Default to the system zone; let UI change it.
    commands.insert_resource(UserTz { tz: chrono_tz::UTC });
}

// Example of converting for display
fn format_time(time: DateTime, tz: &Tz) -> String {
    time.with_timezone(tz).format("%Y-%m-%d %H:%M:%S %Z").to_string()
}

Multiplayer wire format

• Send the epoch as an i64 (seconds) or i128 (nanoseconds) over the network. Integers compare, sort, and hash identically on every client.
• If you prefer a human‑readable string, use RFC 3339 without an offset (e.g., 2024-10-13T05:46:42Z), but keep the underlying value in UTC.

Verification steps

1. Run the game on two machines in different TZ settings.
2. Trigger an event that records a timestamp.
3. Save the file and load it on the other machine; confirm the epoch value is identical.
4. Display the timestamp using format_time with each machine’s chosen Tz; the displayed string should differ, but the underlying data remains the same.
5. Run a deterministic fixed‑step simulation twice with Time::Virtual only, compare state hashes, then repeat with Utc::now() injected; the first pair should match, the second should diverge.

When zone‑aware persistence might be needed

If your application must keep the original local time for audit or compliance reasons (e.g., legal logs), you can store an additional field containing the local representation. Keep the canonical UTC field for all game logic and replay. In that case, the extra field is never used for deterministic calculations.

Ask for missing diagnostic detail

Does your game need to record the exact local time of past events for audit or compliance purposes? If not, stick to UTC storage only.