Scheduler fails to run: Scheduler failed to find next date

Possibly related to https://forum.duplicati.com/t/cant-access-front-page-after-logging-in-argumentoutofrangeexception-duetime/20397

Since running that fix, I have been able to log into the UI and run backups. However, I noticed scheduled backups are not running.
I believe language is the issue here. Display is set to English (Canada), but application language is set to French (Canada) and the regional format is French (Canada).
The error in the Duplicati logs is:

System.Exception: Impossible de trouver une date valide, compte tenu de la date de début 2025-04-02 19:00:00, de l'intervalle de répétition 2h et des jours autorisés Monday, Tuesday, Wednesday, Thursday, Friday, Saturday, Sunday
   at Duplicati.Server.Scheduler.GetNextValidTime(DateTime basetime, DateTime firstdate, String repetition, DayOfWeek[] allowedDays)
   at Duplicati.Server.Scheduler.Runner()

This translates to “Cannot find a valid date, given a start date of 2025-04-02 19:00:00, interval of 2h in allowed days Monday, Tuesday, Wednesday, Thursday, Friday, Saturday, Sunday”
I have a funny feeling this is because the mentionned days are in English, and the Regional Format expects them to be in French, which results in not being able to find the allowed days.

Alright, so I changed the scheduler from running every 2 hours to every day. Suddenly, it works…
I’m heavily suspecting that the timezone is the issue here. I’m in EST -4, and the Schedule table shows ‘Time’ as a timestamp (and the error logs also mention it in UTC). I believe Duplicati is comparing this UTC time to the non-UTC system time.

Here’s an example of the described bug:
The next scheduled backup is at 14:00 EST -4 (which is 18:00 UTC). This is stored in the database in the “Schedule” table, in the corresponding backup’s row, in the column “Time” as a timestamp (which are always UTC).
Backups are scheduled to run every 2 hours. The next backup would be at 16:00 EST -4 (which is 20:00 UTC).
In this instance, I believe any interval equal or below 4 hours would fail. This is equal to the timezone difference between UTC and the system.

Thoughts?

I just checked and it is wierder than that. At 14:32, the schedule runs with an “every 23 hours” set. It runs, but for some reason, it sets the next scheduled time to 23:00 of the same day (today) ?
I am just confused now.

This is probably the same issue as we uncovered, where 0s is a valid date. I just tested and 2h also parses as a valid date under fr-CA. This wreaks havoc on the date counter because the calculated next date (+2h) is before the current one.

This is actually an implementation detail, because I did not consider these for localization, so they are an internal enumeration of days that are translated here, not the regular day names, which would be localized.

Yes, I can see that 1D is not a valid date, so that would work.

That is because 23h is a valid date under fr-CA, so it will then always calculate the next date to be “today at 23:00 local time”, and not time + 23h as it is supposed to.

I have a fix ready in the 2.1.0.113 canary that will be up soon.

1 Like

New update seems to break the UI when it comes to backup schedules. You can set up multiple schedules for a single backup because the UI (both NGAX and NGCLIENT) will always report backups as having no set schedules, and will allow you to create a new one everytime. The times shown on the UI also no longer match when more than 1 schedule is set for the same backup, only the first created schedule will be shown (NGAX only). The top status bar’s next scheduled backup is correct, however.

TL;DR for both NGAX and NGCLIENT:

  • The UI always shows the backup schedule as off;
  • Every time you setup a backup schedule, it creates a new entry in the Schedule table in the database;
  • None of the backup schedules are shown in the backup’s edit/setup wizard;
  • The backup will respect all of its schedules.

Although initially looks like a bug, it could definitely be a nice feature if it gets properly handled on the UI side.

Thanks for reporting this. I have fixed it in 2.1.0.116.

If you have saved the backups with a new schedule, there is a chance that you now have multiple schedules for the backups. Let me know if you need assistance clearing up that mess.