Is your feature request related to a problem? Please describe.
We would like to start our workflows every day at a specific time. However, for us, it is very important that the workflow is started at a specific local time (e.g. 9AM Zurich time). As this workflow is related to the working hours. Currently, the documentation mentions that the workflow only works with UTC times. An easy way around the problem would be to convert the time before writing UTC, however, then we would not have DST changes reflected in the cron.

Describe the solution you'd like
It seems that temporal already could support timezones as the library used already provides timezone support (https://github.com/robfig/cron). I would like to see that support being made official, so that our cron strings do not break with version upgrades.

The cron string would look like:

// CronSchedule - Optional cron schedule for Workflow. If a cron schedule is specified, the Workflow will run
// as a cron based on the schedule. The scheduling will be based on UTC time. The schedule for the next run only happens
// after the current run is completed/failed/timeout. If a RetryPolicy is also supplied, and the Workflow failed
// or timed out, the Workflow will be retried based on the retry policy. While the Workflow is retrying, it won't
// schedule its next run. If the next schedule is due while the Workflow is running (or retrying), then it will skip that
// schedule. Cron Workflow will not stop until it is terminated or cancelled (by returning temporal.CanceledError).
// The cron spec is as follows:
// ┌───────────── minute (0 - 59)
// │ ┌───────────── hour (0 - 23)
// │ │ ┌───────────── day of the month (1 - 31)
// │ │ │ ┌───────────── month (1 - 12)
// │ │ │ │ ┌───────────── day of the week (0 - 6) (Sunday to Saturday)
// │ │ │ │ │  ┌─────────────  Optional timezone parameter for the cron schedule. 
// │ │ │ │ │  |
// * * * * * CRON_TZ=UTC

To my limited knowledge, the cron is implemented as a delayed task after each completion. Therefore, this should work out of the box already today. (Even the format should be supported).

However, this is not documented as of today and also not tested.

Describe alternatives you've considered
There are no real alternatives to this solution.