Firebase Realtime Database offline persistence loses write timestamps during concurrent client updates

The goal is to understand whether locally queued writes retain their original client‑generated timestamps when multiple clients update the same location while offline and later reconnect.

When network connectivity is lost, the SDK persists each write in an offline queue. Upon reconnection, the server reconciles these queued operations. It is unclear whether the SDK preserves the timestamp supplied by the client’s set() or transaction call, or if it replaces it with a server‑assigned time, potentially altering the expected order of concurrent updates.

Does the Firebase Realtime Database SDK retain the original client‑generated timestamp when persisting writes offline and reconciling after network loss? How does concurrent write conflict resolution interact with timestamp preservation? Are there SDK methods or configuration options that can force client timestamp retention during offline sync?