Behavior of DateTime::setTimezone During Ambiguous and Non‑existent DST Transitions

Goal: Verify the exact offset PHP selects when a DateTime representing an ambiguous local time (e.g., 01:30 am during a fall‑back transition) is converted with setTimezone to a zone that observes the same offset, and whether the result is consistently the earlier offset.

Constraint: This behavior is not documented as a rule and may vary with timelib updates; additionally, DateTimeZone::getTransitions only returns transitions present in the bundled or system timezonedb, which may lack future DST rule changes.

Questions: Does PHP guarantee the earlier offset for ambiguous times across all supported releases? Is the forward shift applied to non‑existent times (spring‑forward gap) stable between versions? How can an application reliably detect and handle these cases without relying on undocumented behavior?