Zend_Date setTimezone() missing validation for timezone identifiers

Direct answer

Should setTimezone() throw? Not in archived ZF1 without an explicit backward-compatibility break. Validate at the application boundary and fail fast there. Which exception? If you patch the core, use SPL InvalidArgumentException for unknown or malformed zone strings. Warning plus UTC fallback? That is the least disruptive for backward compatibility, but it preserves the hazard: bad input still yields a plausible UTC date. If chosen, make the fallback explicit and log the offending identifier with the resolved zone.

Likely explanation vs. confirmed facts

The reported silent UTC fallback is consistent with ZF1 normalizing unknown zones through PHP timezone functions, but the exact code path is unverified here. Confirmed: PHP can validate identifiers via new DateTimeZone($id) or DateTimeZone::listIdentifiers(). Treat any specific exception class, message, or fallback behavior in ZF1 as unverified until reproduced on your stack.

Steps for this case

1. Validate at the boundary. Use DateTimeZone as a gate before constructing or mutating Zend_Date.
2. Fail fast on bad input. If the identifier comes from user input or configuration, throw InvalidArgumentException at the call site rather than letting Zend_Date silently continue.
3. If patching core, keep it minimal. Add an SPL InvalidArgumentException for unknown or malformed zone strings, and cover invalid, alias, and deprecated identifiers with tests. Avoid inventing a Zend-specific exception unless matching existing conventions.
4. If you must preserve compatibility, a warning plus explicit UTC fallback is less disruptive, but it preserves the hazard. Log the offending identifier and the resolved zone.

Verification

Reproduce on your exact PHP and ZF1 1.12.x build before changing behavior:

<?php
// 1. Check whether PHP rejects the identifier on this host
try {
    $tz = new DateTimeZone('Not/A_Zone');
    echo "PHP accepted: " . $tz->getName();
} catch (Exception $e) {
    echo "PHP rejected: " . $e->getMessage();
}

// 2. Compare Zend_Date behavior for the same instant
$bad = new Zend_Date();
$bad->setTimezone('Not/A_Zone');
echo $bad->toString('YYYY-MM-dd HH:mm:ss');

$utc = new Zend_Date();
$utc->setTimezone('UTC');
echo $utc->toString('YYYY-MM-dd HH:mm:ss');
?>

If DateTimeZone throws while Zend_Date does not, the missing validation is in the Zend layer. Also inspect the installed Zend_Date source for setTimezone and any normalization or fallback to UTC/date_default_timezone. Check the installed timezone database version and DateTimeZone::listIdentifiers() for aliases and deprecated names before deciding an identifier is truly invalid.

One missing diagnostic detail

Are bad identifiers only entering at call sites from user input or configuration, or are they also embedded in persisted Zend_Date values that must be re-read? Call-site-only argues for boundary validation; persisted values argue for a repair/migration plus strict parsing.