ISO8601DateFormatter storage vs NSDateFormatter local display for a cross-timezone event app

Context

I am designing date handling for an iOS app (Xcode 15+, Swift, targeting iOS 15 and later) that stores event times on a server and displays them to users who travel across regional time zones. The hard constraint is that stored values must round-trip deterministically, while the UI must always reflect the user's current device time zone.

The trade-off

One option is to persist everything with ISO8601DateFormatter (or Codable's ISO8601 strategy) in UTC and convert to local only at display time with NSDateFormatter configured with locale and timeZone. The other is to store the user's local wall-clock time plus a time-zone identifier, preserving the original intent (e.g., "9 AM Tokyo") even if the user later moves.

My uncertainty: Calendar.current.component(_:from:) silently follows the device's default time zone, so any grouping logic (e.g., "events today") can shift when the user changes regions, and DST transitions risk off-by-one-day errors in either model.

Questions

1. For events anchored to a physical location, is storing UTC instants sufficient, or is the local-time-plus-zone model the safer documented pattern?
2. When grouping by day, should I derive the calendar's time zone from the event's stored zone rather than Calendar.current?
3. Are there known parsing ambiguities when mixing NSDateFormatter.defaultTimeZone with fixed ISO8601 strings on older iOS versions?