GraphQL Order Timestamps vs Store-Scoped Timezone Config: Where Should Conversion Happen?

Integration boundary

We are exposing order data from Magento 2.x through the native GraphQL API to a headless storefront. Date fields such as created_at come back as UTC ISO 8601 strings, while the store view is configured with a regional timezone under Stores > Configuration > General > Locale Options. The storefront must display order times in the shopper's local store timezone, and we need to decide where that conversion belongs.

Constraints and uncertainty

All timestamps are stored in UTC in the database, and PHP's date.timezone must remain UTC for Magento's internal conversion logic to work correctly. The schema appears to offer no built-in directive or argument to return dates pre-converted to the store timezone, so a custom resolver or client-side conversion seems necessary. We also have third-party modules that read the store timezone via ScopeConfigInterface, and we are concerned about double-conversion if a custom GraphQL resolver applies TimezoneInterface formatting while a module has already adjusted the value. Assume a current Magento 2.4.x release; behavior should be verified against the installed version.

Open questions

• Is wrapping date fields in a custom resolver that uses \Magento\Framework\Stdlib\DateTime\TimezoneInterface the supported extension point, or is client-side conversion the intended pattern?
• How can we detect whether a third-party module has already converted a timestamp before our resolver runs, to avoid double offsets?
• Does store-scoped timezone config resolve correctly in GraphQL context for multi-store setups, given the store header?