Schedules run in your timezone

Cron fields are wall-clock fields, so a schedule that means 09:00 in Berlin cannot be stored as a UTC expression. The UTC hour moves twice a year. Every schedule used to be UTC and the console said so plainly, which left you doing the arithmetic yourself and redoing it every spring.

A schedule now carries a timezone. Set your default in Settings and new schedules start from it. The interview reads that default too, so telling it "every weekday at 9" stops being a conversation about which 9. If you have not set one, it asks rather than assuming.

The console shows the next run under the cron line, which is where the zone stops being decoration: the digits alone do not tell you when the next occurrence actually is. A zoned schedule reads local first with UTC beside it, because the hour that repeats when the clocks go back gives two different instants the same local name.

Both daylight saving edges are handled, and the contract is that your schedule fires once. A local time that does not exist on the spring-forward day runs at the first instant after the gap. On the fall-back day it fires on the first of the two, never twice.