Fix: fall back to UTC for timezones a service cannot resolve

[alies-dev]

Context and Purposes

A DateTimeZone does not have to name a place. Parsing any ISO 8601 string with an offset gives you one that does not:

$from = new DateTimeImmutable('2026-01-01T10:00:00+02:00'); // zone name: "+02:00"

The generators passed that name straight through, and both services broke on it.

Google received &dates=20260101T100000/20260101T110000&ctz=+02:00. Live testing against calendar.google.com shows ctz=+02:00 is ignored in every encoding, so the wall clock pair in dates was reinterpreted in the viewer's own timezone. The event silently landed at the wrong absolute time for every viewer outside +02:00, and the stz/etz pair on the distinct timezone path failed the same way. The same testing disproved the comment in Google.php claiming Google handles unencoded names such as Etc/GMT+5: that family is rejected both raw and fully percent encoded, so no encoding makes it work.

ICS received DTSTART;TZID=+02:00:20260101T100000. RFC 5545 defines a param-value as text that cannot carry an unquoted : (section 3.1), so a conforming parser reads the parameter as TZID=+02 and takes 00:20260101T100000 as the property value, which is not a valid DATE-TIME. The event was corrupt in every client, and negative offsets failed identically. A TZID also has to name a zone the client can look up (section 3.2.19), which an offset never does.

Both are the same underlying question, so the answer lives in one place. Link::hasResolvableTimezones() reports whether both ends carry a name a calendar service can resolve, and both generators ask it:

• a TZDB region name (Europe/Amsterdam, including the backward names such as US/Pacific) resolves, and so does UTC;
• an offset (+02:00) or an abbreviation (CEST) names no region and carries no daylight saving rules;
• Etc/GMT±N is a real TZDB identifier, but its sign is inverted from the offset it names and Google rejects it outright;
• the region-less legacy names (EST, MST7MDT) are POSIX rules rather than places.

When the answer is no, the generators write the unambiguous UTC form instead. Google gets dates=20260101T080000Z/20260101T090000Z and no ctz, stz or etz. The ics file gets UTC DTSTART/DTEND and no TZID. The instant is preserved in both, which is what was being lost.

Both ends are judged together. Naming only the departure of a flight whose arrival zone is an offset would leave the two halves of one event on different footings, so an unresolvable zone at either end sends the pair to UTC.

An all-day event is the one case that is not converted. Its endpoints are calendar dates rather than instants, and rewriting them in UTC would shift a midnight in +02:00 back onto the previous day. Those dates stay as they were given and only the ctz naming is dropped.

Nothing changes for an event that already names a region: every existing snapshot is untouched.

Fixes #234

[alies-dev]

Merge-order note: #249 adds VTIMEZONE components gated on Ics::shouldDefineTimezones(), which currently returns $link->hasDistinctTimezones(). This PR narrows the condition for writing TZID to hasDistinctTimezones() && hasResolvableTimezones(). Whichever lands second should bring the two gates back in step, otherwise an event with an offset style zone gets VTIMEZONE components that nothing in the file references.