Intl.DateTimeFormat timeZone option or manual offset math for zone-correct display?

A scheduling dashboard stores every timestamp in UTC but must render each one in a per-user IANA zone such as America/New_York or Asia/Tokyo, without mutating the stored instant.

Two documented paths

Intl.DateTimeFormat (ECMA-402) takes a timeZone option: it formats an existing Date in a named zone and leaves the underlying epoch untouched. The alternative is manual offset arithmetic — reading an offset via Date.prototype.getTimezoneOffset or a hard-coded value, shifting the Date by that many minutes, then formatting the shifted copy, whose internal timestamp now differs from the stored one.

Where they diverge

The open concern is daylight-saving behavior. A fixed manual shift can produce wall-clock times that land in a spring-forward gap or repeat during fall-back, and it pushes zone-rule lookup onto the application. The Intl path delegates those rules to the runtime's ICU data, but formatting output can vary with the engine's ICU version, and legacy environments such as IE11 lack timeZone support entirely.

Assume modern evergreen browsers and Node.js with full ICU data, where ECMA-402 timeZone support is complete; IE11 is out of scope.

For a store-in-UTC, render-per-zone design, which approach holds up more reliably across DST boundaries? And is depending on runtime ICU data an acceptable consistency risk across browsers?