Appwrite datetime attributes return UTC only: where should per-user timezone conversion live in a multi-region app?

Appwrite Databases store datetime attributes and system timestamps such as $createdAt and $updatedAt as ISO 8601 strings normalized to UTC. Values written with an offset like 2026-10-14T10:00:00+05:30 come back in UTC, and no per-user or per-document timezone metadata is attached. This means every layer of the stack receives UTC and nothing else.

For an app with users across many regions, the open design question is where conversion belongs. Client-side conversion with the browser's Intl.DateTimeFormat works for display, but Appwrite Functions run server-side with no per-request user locale, so any scheduling or day-boundary logic needs the user's IANA zone passed in explicitly. Storing the zone (e.g. Europe/Berlin) as a profile attribute handles DST correctly, unlike fixed offsets, but adds a lookup step to every server-side operation.

A related pitfall is date-only data: modeling a birthday or due date as a UTC-midnight datetime shifts the calendar day for users behind UTC.

Is storing an IANA zone per user and converting at read time the accepted pattern, or is there a documented Appwrite mechanism I am missing? Should date-only fields be modeled as plain strings instead of datetime attributes? Does this behavior differ between Appwrite Cloud and recent self-hosted versions?