Cloud Scheduler Time Zone and Cloud Functions UTC Timestamps: Who Owns Local-Time Interpretation Across DST?

We schedule Cloud Functions (2nd gen) via Cloud Scheduler jobs configured with an IANA time zone such as America/Los_Angeles. The jobs trigger correctly most days, but the design intent is ambiguous around daylight-saving transitions and around how the function should interpret the delivery time.

My understanding is that Cloud Scheduler converts the cron schedule from the configured local time zone to UTC internally, and that the event timestamp delivered to the Cloud Function is in UTC. That leaves two gaps: what happens to a job scheduled at a local time that falls inside the spring-forward gap (e.g., 02:30 on the transition date), and whether the function can recover the scheduler's configured local time from the event payload at all, or must hard-code the zone for conversion.

A second constraint: the time zone is fixed per job and cannot be overridden per invocation, so a multi-region workload seems to require one job per region rather than dynamic switching.

Specifically:

• On a spring-forward date, is a 02:30 local-time job skipped, delayed to the next valid instant, or run at a shifted UTC time?
• Is there any field in the scheduled trigger event that carries the job's configured time zone, or must the function assume it?
• For multi-region schedules, is one job per region the supported pattern, or is there a documented alternative?