AT TIME ZONE selects earlier offset during ambiguous DST fall-back without disambiguation option

SQL Server's AT TIME ZONE function converts naive datetime or datetimeoffset values to a target Windows time zone using the host OS's time zone database. During the fall-back daylight saving transition, a local clock time such as 2023-11-05 01:30 occurs twice—once in daylight time (UTC-4) and once in standard time (UTC-5). The function deterministically returns the earlier offset (standard time) and provides no parameter or hint to select the later offset.

This behavior is consistent across SQL Server 2019 and later, but the underlying Windows time zone rules can differ between OS patch levels, causing cross-environment discrepancies. Applications that require precise historical timestamps—such as audit logs or financial records—cannot rely on implicit conversion alone, because the chosen offset may not match the intended instant.

There is no built-in function to enumerate all valid offsets for a given local time in a zone, nor does AT TIME ZONE support IANA identifiers that might offer richer disambiguation metadata.

• Can an application reliably detect whether a converted value fell in the ambiguous hour without storing the original offset?
• Which patterns ensure consistent disambiguation across Windows Server 2019 and 2022 when OS time zone updates diverge?