Gitea Actions cron triggering at the wrong time #14343

Closed
opened 2025-11-02 11:10:23 -06:00 by GiteaMirror · 4 comments
Owner

Originally created by @geek-at on GitHub (Apr 7, 2025).

Description

Hello!

My Gitea Version: Gitea version 1.23.6 built with GNU Make 4.4.1, go1.24.1 : tidb, sqlite, sqlite_unlock_notify running on Alpine Linux.

I have a very simple workflow to be executed with my act runners: from my repo at .gitea/workflows/cron.yaml

name: cron test

on:
  schedule:
    - cron: '0 0 * * *' # every day at midnight
    - cron: '0 23 * * *' # every day at 23:00

jobs:
  crontest:
    runs-on: ubuntu-latest
    steps:
      - run: echo "Running cron by a ${{ github.event_name }} event."
      - run: echo "The time is $(date)"

So this cron should trigger twice: Once at midnight, once at 11PM but instead it triggers at the following times yesterday

    1. Apr. 2025, 1:00 AM MESZ
    1. Apr. 2025, 2:00 AM MESZ
      It seems to have started with the start of summertime last week. Before that it triggered at the correct time and now it's off by two hours.

What I have checked and done:

  • Verify that the time is correct on the act runners and on the gitea server
  • Verify that the time is correct on all act runners
  • Configured the DEFAULT_UI_LOCATION in the app.ini which seems to be the only timezone related setting
  • Restarted Gitea and the host VM
  • Re-pushed the repository containing the cron

Gitea Version

1.23.6

Can you reproduce the bug on the Gitea demo site?

No

Log Gist

No response

Screenshots

No response

Git Version

2.49.0

Operating System

Alpine Linux edge 3.22.0_alpha20250108

How are you running Gitea?

Via the Alpine Package in the edge repository: https://pkgs.alpinelinux.org/package/edge/community/x86/gitea

Database

SQLite

Originally created by @geek-at on GitHub (Apr 7, 2025). ### Description Hello! My Gitea Version: `Gitea version 1.23.6 built with GNU Make 4.4.1, go1.24.1 : tidb, sqlite, sqlite_unlock_notify` running on Alpine Linux. I have a very simple workflow to be executed with my act runners: from my repo at `.gitea/workflows/cron.yaml` ``` name: cron test on: schedule: - cron: '0 0 * * *' # every day at midnight - cron: '0 23 * * *' # every day at 23:00 jobs: crontest: runs-on: ubuntu-latest steps: - run: echo "Running cron by a ${{ github.event_name }} event." - run: echo "The time is $(date)" ``` So this cron should trigger twice: Once at midnight, once at 11PM but instead it triggers at the following times yesterday - 7. Apr. 2025, 1:00 AM MESZ - 7. Apr. 2025, 2:00 AM MESZ It seems to have started with the start of summertime last week. Before that it triggered at the correct time and now it's off by two hours. **What I have checked and done:** - Verify that the time is correct on the act runners and on the gitea server - Verify that the time is correct on all act runners - Configured the `DEFAULT_UI_LOCATION` in the `app.ini` which seems to be the only timezone related setting - Restarted Gitea and the host VM - Re-pushed the repository containing the cron ### Gitea Version 1.23.6 ### Can you reproduce the bug on the Gitea demo site? No ### Log Gist _No response_ ### Screenshots _No response_ ### Git Version 2.49.0 ### Operating System Alpine Linux edge 3.22.0_alpha20250108 ### How are you running Gitea? Via the Alpine Package in the edge repository: https://pkgs.alpinelinux.org/package/edge/community/x86/gitea ### Database SQLite
GiteaMirror added the topic/gitea-actionstype/bugissue/needs-feedback labels 2025-11-02 11:10:23 -06:00
Author
Owner

@nephatrine commented on GitHub (Apr 9, 2025):

I get the same issue since updating to 1.23.6 except mine are all running four hours early instead of two hours late. Probably because my DST/summer timezone is UTC−04:00. Since you seem to be in UTC+02:00 and are seeing jobs two hours late that makes me think Gitea is now running the cron jobs against UTC instead of the local timezone on the server. I was on 1.22.2 previously and everything ran based on my server's local time.

@nephatrine commented on GitHub (Apr 9, 2025): I get the same issue since updating to 1.23.6 except mine are all running four hours early instead of two hours late. Probably because my DST/summer timezone is UTC−04:00. Since you seem to be in UTC+02:00 and are seeing jobs two hours late that makes me think Gitea is now running the cron jobs against UTC instead of the local timezone on the server. I was on 1.22.2 previously and everything ran based on my server's local time.
Author
Owner

@geek-at commented on GitHub (Apr 9, 2025):

good catch I think you're right. It did appear in the last patch and makes sense that it's in UTC. wonder what change might have triggered this. Any ideas @lunny ?

@geek-at commented on GitHub (Apr 9, 2025): good catch I think you're right. It did appear in the last patch and makes sense that it's in UTC. wonder what change might have triggered this. Any ideas @lunny ?
Author
Owner

@TheFox0x7 commented on GitHub (Apr 9, 2025):

Default timezone was changed in 1.23 (PR) to match Github's behavior.
Apparently you can force your own timezone with TZ= parameter.

@TheFox0x7 commented on GitHub (Apr 9, 2025): Default timezone was changed in 1.23 ([PR](https://github.com/go-gitea/gitea/pull/31742)) to match Github's behavior. Apparently you can force your own timezone with `TZ=` parameter.
Author
Owner

@geek-at commented on GitHub (Apr 10, 2025):

Ok it works when I configure my crons with the TZ parameter

on:
  schedule:
    - cron: 'TZ=Europe/Vienna 0 18 * * *' # daily at 18:00
@geek-at commented on GitHub (Apr 10, 2025): Ok it works when I configure my crons with the TZ parameter ```yml on: schedule: - cron: 'TZ=Europe/Vienna 0 18 * * *' # daily at 18:00 ```
Sign in to join this conversation.
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: github-starred/gitea#14343