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

Answer

PHP does not guarantee the earlier offset for ambiguous local times, nor does it guarantee a specific forward shift for non‑existent times. The offset that ends up in the DateTime after calling setTimezone is the one that was in effect when the object was originally created, because setTimezone preserves the underlying Unix timestamp and only changes the displayed wall‑clock time.

Confirmed facts

• DateTime::setTimezone never modifies the stored Unix timestamp; it replaces the timezone identifier and recomputes the hour/minute/second to represent the same instant.
• Since PHP 5.5 the timestamp is preserved correctly; earlier versions could incorrectly adjust the timestamp when changing zones.
• When a DateTime is constructed from a string that falls inside a DST gap (e.g., 02:30 am on a spring‑forward day), PHP moves the time forward by the gap (or emits a warning) and stores the resulting valid timestamp.
• When the string represents an ambiguous time (e.g., 01:30 am during a fall‑back), PHP chooses the offset that was in effect at the moment of parsing – usually the later offset – and stores that timestamp.

Likely explanation

The behaviour depends only on the Unix timestamp stored in the DateTime object. Any DST ambiguity is resolved at construction time; setTimezone simply re‑expresses that instant in the target zone, so the result is consistent as long as the construction step is consistent.

Steps to verify

1. Create a DateTime for the ambiguous time: $dt = new DateTime('2023-11-05 01:30:00', new DateTimeZone('America/New_York'));
2. Record the timestamp: $ts = $dt->getTimestamp();
3. Change to a zone that observes the same offset (e.g., Europe/London during winter): $dt->setTimezone(new DateTimeZone('Europe/London'));
4. Check the timestamp again; it should be identical to $ts on PHP 5.5+.
5. Repeat with a non‑existent time (e.g., '2023-03-12 02:30:00') and note any warning; the timestamp after setTimezone will remain the adjusted value.

Missing diagnostic detail

To be certain which code path applies, please confirm your PHP version (output of phpversion()). If it is older than 5.5 the timestamp may change after setTimezone, requiring a workaround such as cloning the object or using DateTimeImmutable.