XSD dateTime offset serialization discards IANA timezone identifier context

Goal

Preserve geographic timezone context when exchanging xs:dateTime values across XML documents and services.

Constraints and uncertainty

The XML Schema specification defines dateTime, date, and time types with an optional offset suffix (±hh:mm or Z) but provides no mechanism to attach a named IANA timezone identifier such as America/New_York. Schema validation only verifies lexical format and offset range (±14:00); it cannot confirm that an offset matches historical rules for any geographic zone. XSD 1.1 introduces xs:dateTimeStamp (which requires an offset) and assertions, yet still lacks a facility to bind a value to a timezone database entry. Major parsers (Xerces, Saxon, .NET System.Xml) expose the offset as a string or numeric minutes and perform no DST-aware conversion unless the calling code uses a separate timezone library. Consequently, a value generated in Europe/Paris summer time (+02:00) serialises as +02:00, and a consumer cannot reliably reconstruct the original zone without out-of-band metadata.

Questions

1. What patterns allow applications to reliably reconstruct the original IANA zone from an offset-only xs:dateTime?
2. Can schema assertions or companion metadata elements enforce offset-to-zone consistency without custom validation code?
3. Are there emerging standards or vendor extensions that embed zone identifiers alongside XSD dateTime values?