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.

Important

Please do not comment "waiting...", "+1", "need this", etc.

It adds nothing to the conversation and spams inboxes. Instead, leave a thumbs up and/or upvote to show your interest in this feature.

If you'd like to follow along for any updates to this thread, you can subscribe to the discussion by clicking the "Subscribe" button on the sidebar.

[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.

[ghost]

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.

[nebuk89]

Sorry no one has commented on this for a while, I will add this to our papercut backlog we are working though. I don't have a timeframe right now but I will check what the effort is. Thanks for your patience with this <3

[github-actions[bot]]

💬 Your Product Feedback Has Been Submitted 🎉

Thank you for taking the time to share your insights with us! Your feedback is invaluable as we build a better GitHub experience for all our users.

Here's what you can expect moving forward ⏩

• Your input will be carefully reviewed and cataloged by members of our product teams. 
  • Due to the high volume of submissions, we may not always be able to provide individual responses.
  • Rest assured, your feedback will help chart our course for product improvements.
• Other users may engage with your post, sharing their own perspectives or experiences. 
• GitHub staff may reach out for further clarification or insight. 
  • We may 'Answer' your discussion if there is a current solution, workaround, or roadmap/changelog post related to the feedback.

Where to look to see what's shipping 👀

• Read the Changelog for real-time updates on the latest GitHub features, enhancements, and calls for feedback.
• Explore our Product Roadmap, which details upcoming major releases and initiatives.

What you can do in the meantime 💻

• Upvote and comment on other user feedback Discussions that resonate with you.
• Add more information at any point! Useful details include: use cases, relevant labels, desired outcomes, and any accompanying screenshots.

As a member of the GitHub community, your participation is essential. While we can't promise that every suggestion will be implemented, we want to emphasize that your feedback is instrumental in guiding our decisions and priorities.

Thank you once again for your contribution to making GitHub even better! We're grateful for your ongoing support and collaboration in shaping the future of our platform. ⭐

[javixeneize]

Thanks, but, why don’t you let us help you? That’s something that we as a community can easily implement and you just need to review it

is it not all about open source and collaboration?

[DrStrangepork]

Reading the comments here, it is unclear to me whether or not the code responsible for accommodating timezone is public or not. If it is, can someone share which repo and code the community can work with to add this feature?

[data-intelligence-analysis]

I would like to know this as well since I do have some CI/CD workflows that would be nice to have the timezone feature!

[omnicortex]

I need this feature.

[coltenkrauter]

Since GitHub Actions doesn’t support timezones in cron scheduling yet, here’s a possible workaround to run workflows at local times like 8 AM PST.

name: Run Task at 8 AM

on:
  schedule:
    # Runs at 3 PM UTC (8 AM PDT) and 4 PM UTC (8 AM PST)
    - cron: '0 15,16 * * *'

jobs:
  check_time:
    runs-on: ubuntu-latest
    steps:
      - name: Check if it's 8 AM
        run: |
          current_hour=$(TZ='America/Los_Angeles' date +'%H')
          echo "Current hour in PST: $current_hour"
          
          if [ "$current_hour" == "08" ]; then
            echo "It's 8 AM PST! Running tasks..."
            echo "run_tasks=true" >> $GITHUB_ENV
          fi

      - name: Execute Scheduled Tasks
        if: env.run_tasks == 'true'
        run: echo "Executing scheduled tasks..."

[tkelly-mgm]

For an approximate answer, I noted that the DST transition for America/Los_Angeles was always on certain numbered days of the month. There's no way to indicate instances of weekdays, so I figured that the least bad solution was to run halfway between offsets if we couldn't tell.

schedule:
  # 8 AM PST from week 2 of Nov to week 1 of Mar
  - '0 16 8-30 11 *'
  - '0 16 * 12-2 *'
  - '0 16 1-7 3 *'
  # Between offsets for week 2 of Mar
  - '30 15 8-14 3 *'
  # 8 AM PDT from week 3 of Mar to end of Oct
  - '0 15 15-31 3 *'
  - '0 15 * 4-10 *'
  # Between offsets for week 1 of Nov
  - '30 15 1-7 11 *'

[radiomix]

Setting the timezone for long running scheduled jobs would facilitate our CI/CD pipeline to sync with log4j rotation setup. :-//

[solita-juhosassali]

Any updates on this? We need this feature in our project as well and now have to manually adjust schedule two times per year. We can manage with a workaround provided by @coltenkrauter (thanks by the way!) but it would be way better to just give the timezone and forget about it.

[nebuk89]

We are currently having a look at this to see what we can do :) hopefully this is something we can get moving very soon

[plchampigny]

Haha, hopefully "very soon" will be before march 8 🤣

[nebuk89]

Currently looking like Q1 next year, I will try to get some better updates come Jan <3 thanks for the patience on this one.

[sagivaknin1]

We also would love to have this feature asap.
Following the thread.
Hoping it will be added soon (:

[nebuk89]

We should be on track for end of March for a public beta, public roadmap is updated and has this in :)

[alyasilpiah]

wow finally @nebuk89

[nebuk89]

We are still on track for before the end of the month, thanks for the patience here <3

[nebuk89]

https://github.blog/changelog/2026-03-19-github-actions-late-march-2026-updates/ We are now live :)

Thank you everyone who engaged on this. I know that you all waited and that you were let down at times. I will keep pushing to get our top items closed out on Actions, I will keep being in the community as much as I can from my time to understand what you all need. And please please keep telling us what you need, it is not 'screaming into the void' we are here :)

[Mr0grog]

My work relies on GHA being punctual

FWIW, a 30 minute delay on GHA is not that unusual in my experience. The docs suggest jobs will often have some notable delay, although they make it sound like it should be less than it often is in practice (at least in my many years of usage). If you need tightly timed or frequently-running jobs, you should probably use a different system for them.

An hour-plus delay, on the other hand, really does sound like the time zones are off, or are being treated as static offsets rather than actual zones, which change offsets over the course of the year! Seeing those reports is a major reason I’ve avoided this feature so far, even though I’d really like to have it.

[abaker-sp]

When I modified a Git Actions job to switch from UTC to using the timezone feature (7 days ago), the jobs immediately started having much longer delays in running. The past 4 days, the delay has been 3 1/2 hours. I'm having to revert back to UTC. Here is what I was running:

    - cron: '30 7 * * *'
      timezone: "America/Chicago"    

[codeskipper]

Same here, the execution delays I'm seeing after adding the timezone setting went from under one hour to nearly two hours. A bit confusing as our UTC offset is two hours in summer time.

[jmspereira]

I think that the problem happens even without a timezone defined. I was waiting for this feature to be more stable before starting to use it, and I am also observing a large delay (+ 2 hours) in my cron workflows. In the last 4 years, I have never seen this, only a couple of minutes of delay.

[fseguin-pass]

FYI delays are happening without specifying a timezone, you can upvote this issue: https://github.com/orgs/community/discussions/156282 and hope that GH acts.

[mcassaniti]

I'm likely to get in a bit of trouble, but I just want to say a big thank you. The community knows this has been a long time coming and it's finally here. Thank you for making our lives just that bit easier.

[haeraeus]

❤️

[Tao-Galasse]

Hi! Thanks for the feature :)

Do you know if the on: supports an env variable ? I would like to define my actions like this:

schedule:
  - cron: '0 8 * * *'
  timezone: ${{ vars.TZ }}

[angel-jiakou]

That's not supported currently.