Hello, I have a cron workflow with 0 22 * * * as its schedule. Based on the java-sdk docs, this schedule should run every day at 22:00 UTC. However, it runs 02:00 UTC instead (22:00 UTC−04:00).
Any ideas as to why this might be the case?
Default timezone for Temporal server is UTC.
Yes, it shows 23h 56m 1s which matches the once-per-day schedule. Also double-checked the cronSchedule field, which is 0 2 * * * rather than 22:00 as expected. Currently investigating why that discrepancy exists.
Looks like there was a change that I didn’t catch, and the schedule is indeed 0 2 * * *. Sorry about that!
Follow-up question: is it possible to configure the Temporal server timezone?
tihomir
November 3, 2021, 11:52pm
5
Here is a feature request to support time zones in cron schedules:
opened 11:51AM - 03 Feb 21 UTC
enhancement
CRON
difficulty: medium
**Is your feature request related to a problem? Please describe.**
We would lik… e 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.
Feel free to add your input there as well.
1 Like