Realm Date Storage vs. Local UI Timezone Conversion: Need for Explicit Timezone Persistence?

Answer first

Realm’s Date type stores an absolute point in time as UTC epoch milliseconds. No timezone is persisted. For displaying the same instant in the device’s current timezone, no explicit timezone persistence is needed. Persist an explicit timezone identifier only if you must reconstruct the original local wall-clock time the user entered, e.g., a meeting that should always show as 9:00 in Europe regardless of where the device is later used.

Confirmed facts

• Realm stores Date as UTC epoch milliseconds; the type represents an instant, independent of local timezone.
• Synchronized Realms converge on the same instant across devices because the stored value is UTC.

Likely explanation for your constraints

Backward compatibility and minimal storage overhead favor keeping Date alone and doing conversion in the UI. Adding a timezone field adds per-object storage and migration work, and is only justified when original local time must be preserved across devices and locale changes.

Migration implications for adding a timezone field to synchronized Realms

1. Bump schemaVersion and add an optional String property, e.g., timeZoneIdentifier, to the model.
2. In the migration block, enumerate existing objects and leave the new property nil. No per-object write is required if the property is optional.
3. For synchronized Realms, the schema change propagates to all clients. Clients receive the new field with its default nil value for legacy objects.
4. Making the field required forces a write pass to backfill every existing object, which is costly and risks conflicts in sync.

Query performance impact

• A String column adds small storage overhead per object. Disk and memory impact is negligible for most apps.
• Queries on the UTC Date are unchanged. Indexing the timezone string only helps if you filter or sort by timezone; indexing adds write cost and index size.

Optional vs required and legacy handling

• Make the identifier optional. New objects can set it at creation; legacy objects remain nil.
• On read, treat nil as “use device current timezone”. This preserves existing behavior.
• If you later need a required field, first backfill legacy rows with a safe default such as UTC or unknown, then change the schema.

One missing diagnostic detail that changes the recommendation: do your user stories require preserving the original local wall-clock time for future-dated events across devices, or is displaying the instant adjusted to the current device timezone sufficient?