Automatic Syncing has wrong time on new install #170

New Issue

2026-10-05T01:45:39+02:00

adam commented

2026-10-05 01:45:39 +02:00

I think on the new install the Automatic Syncing has the timer initialized to first login time or something closer to that. My timer was stuck at 3PM despite it shows the default 10PM above. I have to turn it off and back on to have the value applied. Probably the timer time and the config time are 2 separate fields so they were out of sync.

I think on the new install the Automatic Syncing has the timer initialized to first login time or something closer to that. My timer was stuck at 3PM despite it shows the default 10PM above. I have to turn it off and back on to have the value applied. Probably the timer time and the config time are 2 separate fields so they were out of sync. <img width="733" height="550" alt="Image" src="https://github.com/user-attachments/assets/5a250c9c-0772-40c9-8689-0e236530683b" />

adam closed this issue

2026-10-05 01:45:39 +02:00

adam commented

2026-10-05 01:45:40 +02:00

Good catch, and your guess was close: the card and the scheduler were reading two different things.

A fresh install started with scheduling enabled on a plain 24 hour interval, with the next run set to first login plus 24 hours. The automation card only knows clock schedules, so for any non-clock interval it rendered the 22:00 placeholder as if it were saved. Toggling the card off and on stored the real clock schedule, which is why that fixed it for you. Docker installs with the compose default GITEA_MIRROR_INTERVAL=8h had the same misreport: the card said 22:00 daily, the scheduler ran every 8 hours.

Fixed in #435, released in v3.36.2:

A new configuration starts with scheduling off unless SCHEDULE_ENABLED, SCHEDULE_INTERVAL or GITEA_MIRROR_INTERVAL turns it on. Enabling from the card stores the clock schedule and your browser timezone, so the card and the scheduler agree from the first save.
When a plain interval is stored, the card now says what runs ("Syncing every 8 hours, counted from the last run") and where it came from, and leaves frequency and start time unset until you pick one.
The timezone chip shows the stored timezone instead of the browser's, and turns into a one-click switch to the browser timezone when they differ.

Your existing install is already on a clock schedule after the toggle, nothing to do there.

Good catch, and your guess was close: the card and the scheduler were reading two different things. A fresh install started with scheduling enabled on a plain 24 hour interval, with the next run set to first login plus 24 hours. The automation card only knows clock schedules, so for any non-clock interval it rendered the 22:00 placeholder as if it were saved. Toggling the card off and on stored the real clock schedule, which is why that fixed it for you. Docker installs with the compose default `GITEA_MIRROR_INTERVAL=8h` had the same misreport: the card said 22:00 daily, the scheduler ran every 8 hours. Fixed in #435, released in v3.36.2: - A new configuration starts with scheduling off unless `SCHEDULE_ENABLED`, `SCHEDULE_INTERVAL` or `GITEA_MIRROR_INTERVAL` turns it on. Enabling from the card stores the clock schedule and your browser timezone, so the card and the scheduler agree from the first save. - When a plain interval is stored, the card now says what runs ("Syncing every 8 hours, counted from the last run") and where it came from, and leaves frequency and start time unset until you pick one. - The timezone chip shows the stored timezone instead of the browser's, and turns into a one-click switch to the browser timezone when they differ. Your existing install is already on a clock schedule after the toggle, nothing to do there.

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: adam/gitea-mirror#170