add timezone support to scheduling workflow runs with cron

[cj81499]

Originally brought up at actions/runner#1423, but I don't think anyone actually started a discussion.

Describe the enhancement
Please add timezones to cron schedules.

Code Snippet

name: Timed action
on:
  schedule:
    - cron: '01 20 * * 1-5'
    - timezone: 'Australia/Melbourne'

Additional information
Especially when the schedule is only supposed to run on certain days of the week this gets very confusing with UTC. Daylight savings does not help much either here.

Among other things, the use case I have in mind is to run a workflow at 10AM local time (the start of the workday), but the best I can do currently is 15:00 UTC (9:00 CST, 10:00 CDT) or 16:00 UTC (10:00 CST, 11:00 CDT), meaning that ~half the year, it'll run at an undesirable time.

[rahulmr]

Why isn't this implemented yet? gitlab is already having this functionality afaik

[Starttoaster]

GitLab, in general, is way ahead of GHA in most features, having been in the CI market longer. So it shouldn't be a huge surprise noticing GitHub is well behind in yet another feature I'm interested in.

[rahulmr]

Any existing workaround? Also, I see that the workflow is sometimes not triggered at all even though I have my own runner which is in idle state.

[ethomson]

Thanks for the feedback @cj81499. I certainly agree that time zones and scheduling is tricky, so I'll make sure that this is on the backlog.

[ajimae]

waiting...

[cj81499]

Hey @ethomson, I took a look at your profile and notice that you're no longer working at GitHub. Did this ever make it onto a backlog that we can watch for updates? If not, any chance you could forward it along to an (ex-)coworker? I think it's clear from the upvotes and thumbs ups in this discussion that there are quite a few people (myself included) that would really benefit from this feature. Thanks!

[cj81499]

Also, for anyone else, please do not comment "waiting..." (or similar). It adds nothing to the conversation and spams our inboxes. Instead, a thumbs up or upvote is a great way to show interest.

If you'd like to follow along for any updates to this thread, you can subscribe to the discussion.

[bbrewington]

I reached out to a member of MS Github Actions team here: actions/runner#1177 (comment)

Not entirely sure if that issue is related, but hopefully it helps this group to get a better answer to an issue that has clear popularity/interest

[cj81499]

@bbrewington thank you for reaching out! I never considered that marking an answer on this thread would reduce the attention it gets, but that idea makes a lot of sense to me. I'll unmark it to see if that draws some additional attention our way.

[ruettenm]

We are also interested in this feature. Are there any plans to implement a timezone support?

[vincentneo]

Just bringing up another use case that would benefit with the addition of this, in case it further helps convince the addition of this feature.

For asian timezone regions, such as here in Singapore (GMT+8), a relatively simple use case of running a workflow on midnight of every 1st day of the month, is basically impossible to schedule as:

12AM here on the first day of the month would be have been basically impossible to write with cron, since, it would require writing it as 4PM of the last day of the month could be 28, 29, 30 or 31.

For example:
12AM (GMT+8) at 1 October would be 4PM (UTC) at 30 September.

Having this would make it easy to schedule with just a 0 0 1 * *, with Singapore's timezone.

[villelahdenvuo]

Another really useful feature would be to be able to add random jitter like cron supports because we can run into ratelimits when we have multiple actions running at the same time.

[cj81499]

@villelahdenvuo While I agree that'd be useful, I believe it's different enough from my proposed feature to justify its own discussion post. If you make one, please share it with me!

[bbrewington]

In case it helps, Jenkins has the “H” thing and I believe it’s implemented here: https://github.com/jenkinsci/jenkins/tree/master/core/src/main/java/hudson/scheduler

[bcowdery]

As a super hacky workaround, you can schedule your workflow to run at BOTH standard and daylight times, and then use a bash script to filter out the undesirable runs. This means you'll have 2 runs for every schedule date, but only one of them will execute past the Test schedule step.

Something like this should work:

on:
  schedule:                             
    - cron: "00 18,19 * * TUE"    # Run every tuesday at 12:00 noon MDT (GMT-6) and MST (GMT-7)

env:
  TZ: "America/Edmonton"
  LOCAL_TIME: "12:00"
  
jobs:
  test-date:
    runs-on: ubuntu-latest
    steps:
      - name: Test schedule
        if: github.event_name == 'schedule'
        run: |
          now=$(date +%s)
          local_time=$(date -d "$LOCAL_TIME" +%s)

          if [[ $now -gt $local_time && $now -lt "$((local_time + 3600))" ]]; then
              echo "🌞 Passed daylight savings time check!"
          else    
              echo "⏱ Waiting until $LOCAL_TIME."
              exit 1
          fi

[stolsvik]

Well, yes, you can set the schedule to run every minute, and reimplement the cron solution, this time in a sane way with TZ support.

It is just very sad.

[nstein-gpjoule]

I've created a Workaround like @bcowdery, but mine won't fail the run:

on:
  schedule:
    - cron: '5 16,17 * * *'

jobs:
  check-run:
    runs-on: ubuntu-latest
    outputs:
      run: ${{ steps.check_local_time.outputs.run }}
    steps:
      - name: Check local time
        id: check_local_time
        env: 
          TRIGGER: ${{ github.event_name }}
        run: |
          echo "Trigger: ${TRIGGER}"
          if [[ ${TRIGGER} == 'schedule' ]]; then
            echo "Checking daylight saving time"
            if [ $(date --date='TZ="Europe/Berlin" now' +%H) -eq '18' ]; then 
              echo 'Time to run!'
              echo "run=True" >> "$GITHUB_OUTPUT"
            else
              echo "It's not 18:05 local time in Europe/Berlin. Waiting for next execution..."
              echo "run=False" >> "$GITHUB_OUTPUT"
            fi
          else
            echo 'Trigger is not cron, ommiting time check!'
            echo "run=True" >> "$GITHUB_OUTPUT"
          fi
  
  my-job:
    runs-on: ubuntu-latest
    if: needs.check-run.outputs.run == 'True'
    needs: check-run

Still, I would love to not use this workaround, but perhaps this is useful for anybody.

[MartijnHols]

Thanks, but I couldn't make the timezone work with date --date='TZ="Europe/Berlin" now' +%H. I had to change it to TZ="Europe/Berlin" date +%H.

[rahulmr]

GHA guys please do something for this feature

[MissaelHRC]

My team continue waiting for this feature, do you know if GitHub team already have a ticket in progress to attend it? @cj81499 @rahulmr Thanks!

[chandrasekhar-prathap]

This is a much needed feature in GH, any updates on this please.

[razvanvancea]

any progress on this feature? thanks!

[Creator54]

Hi guys any updates on this?
thanks

[dgsauve]

[connorjclark]

Sure. Your comment alerts hundreds of people interested in a meaningful update from GitHub, but instead we got a "me too" reply. Just subscribe to alerts and move along.

[kopax-polyconseil]

Seems like easy to implement and would sove a lot of problem.

[konjoinfinity]

I am very interested in this feature.

[ChrisPage-AT]

I'm not sure why there are so many thumbs down reactions on these comments. This feature would greatly improve usability and bring GHA in line with other cicd offerings. Can we please get any indication if this has made it onto a backlog somewhere or if this won't be implemented? Thanks!

[prangel-stuller]

See connorjclark's comment above on why the thumbs down reactions. If you want to express interest in a feature, do so via reacting to the original post and subscribing for alerts. Don't hit others with unnecessary notifications.

[wt-asw]

also interested in this feature

[elwinschmitz]

As a quick-and-dirty workaround, I've settled on using this schedule in my workflow:

To run a few times during working-hours on week-days only:

schedule:
    # During "Central European Time" (CET): Offset from UTC: -1
    - cron: '42  7,10,13,16  *  11-12,1-3 1-5'
    # During "Central European Summer Time" (CEST): Offset from UTC: -2
    - cron: '42  6,9,12,15   *  4-10      1-5'

During winter-months, it runs on a 1-hour offset, during summer-months on a 2-hour offset.

This will be technically incorrect for a few days per year. But in my case that outweighs the hassle of "having to remember to change the cron-schedule twice every year"...