Was denkst Du denn selbst, was da der Fehler sein könnte?
Wenn man Dir jetzt einen Tipp geben würde, wie man das alternativ berechnen kann, wäre das allerdings deutlich mehr als ein Hinweis auf die Ursache des Problems - aber eigentlich sollte Dir ja schon ein simpler Aufruf von "date" (mit den entsprechenden Optionen) auf der FRITZ!Box mehr als nur einen zarten Hinweis darauf liefern, wo hier das Problem liegt. Insofern kann man
auch schon mal falsch verstehen - nämlich als Aufforderung, das an Deiner Stelle zu lösen.
Daher mal die "Grundlagen": Linux-Systeme (und andere Unix-artige) benutzen zur Darstellung der Uhrzeit gerne einen Zähler, der die Anzahl der Sekunden seit dem 01.01.1970 01:00 Uhr (für MEZ, ansonsten 0:00 Uhr) enthält - dieser Startwert (genannt "The Epoch") gibt häufig auch dem Wert den Namen ("epoch", aber auch "unixtime" oder ähnliches). Der Vorteil zweier Datumswerte in dieser Darstellung ist es, daß man ganz einfach die Differenz zweier Werte bilden kann oder auch problemlos eine bekannte Zeitspanne zu einem anderen Wert addieren kann für künftige "Termine" als auch zur Berechnung zurückliegender Daten subtrahieren.
So kann man auch leicht ermitteln, um wieviele Sekunden sich das Datum vor 31 Tagen vom heutigen unterscheidet, nämlich: 31 * 24 * 60 * 60 = 31 * 86.400 (ein Wert, der sich jedem, der mit Linux-Zeiten rechnen muß, quasi "eingebrannt" hat als Anzahl der Sekunden eines Tages) = 2.678.400 Sekunden. Den Wert muß man nun nur vom aktuellen abziehen (die Funktionen für den Umgang mit "epoch values" bietet praktisch jedes "date"-Kommando, auch das der BusyBox, was die "Kunststückchen" des GNU-Programms (m.E. ohnehin eher brotlose Kunst und mehr "Liebhaberei" des Autoren) nicht mitmacht - die auch dort nur in der "info"-Datei ausführlich beschrieben sind und nicht in dessen Man-Page) und schon hat man einen Wert, den man sich wieder in ein Datum umwandeln lassen kann.
Wobei es hier (auch weil "Schaltsekunden" und deren Einbeziehung nicht klar geregelt sind, zumindest soweit ich weiß) ohnehin wieder schlauer wäre, das "maximale Alter" so eines Ordners festzulegen und dann alles zu löschen, was älter ist ... ansonsten bleibt auch schon mal ein Ordner stehen, weil die Berechnung nicht exakt den Zeitpunkt ergibt, der im Namen enthalten ist. Vielleicht ist es ja auch eine Überlegung wert (kommt halt auf die "Auswertesoftware" an und sogar noch darauf, wie oft man die benutzen muß), das Datum gleich als "epoch" im Dateinamen abzulegen ... das macht dann Vergleiche, ob die Datei vor oder nach einem Datum liegt (u.a. auch solche wie "gib mir alle Dateien der letzten 7 Tage") wieder leichter und solange man die Umrechnung nicht von Hand machen muß, spielt ein "lesbarer" Name auch nicht unbedingt eine Rolle. Zumal man in Verzeichnislisten ja auch oft genug noch das Datum der Erstellung eines Verzeichnisses anzeigen lassen kann neben dem Namen (nicht zu verwechseln mit der "access time") und das wäre dann ja wieder (wenn ich die Idee richtig verstehe anhand der gezeigten "Schnipsel") das aktuelle Datum, wenn man das wirklich "von Hand" durchsehen muß.
Klartext: Ich würde hier eher alle Verzeichnisnamen "einlesen" in das Skript und dann die Auswertung über die Verzeichnisnamen laufen lassen, welche nun Kunst sind und welche weg können ... das dann wieder mit einem gezielten FTP-Aufruf. Im Idealfall (wenn das Skript tatsächlich jeden Tag läuft ... und auch noch jeden Tag
erfolgreich läuft) ist das dann auch wieder nur ein einzelner Aufruf zum Löschen eines Verzeichnisses ... aber wenn es mal schiefgegangen ist und 3 Wochen nichts gelöscht wurde, dann löscht (sofern man meinen "Vorschlag" für die Logik implementiert) auch ein einzelner Aufruf wieder alle betroffenen Verzeichnisse, ohne daß man dafür "Hand anlegen" müßte - was bei einer Logik "Lösche den Ordner, dessen Name das Datum von 'heute vor 31 Tagen' enthält." schon mal nicht möglich wäre.
Aber die möglichen Fehler und ihre Wahrscheinlichkeiten muß ebenso jeder selbst bewerten, wie er sich einen Plan zurechtlegen muß, wie er damit umgehen will und was es ihm an Aufwand wert ist, einen reibungslosen (und unbeaufsichtigten) Betrieb von Beginn an zu planen. Manchmal ist auch das "manuelle Nacharbeiten" eine denkbare Alternative, wenn die Wahrscheinlichkeit von Problemen ohnehin gegen Null geht. In einem Einsatz zweier FRITZ!Boxen würde ich (persönlich) aber noch kein "Hochverfügbarkeitssystem" sehen ... da bleibt schon mal die eine oder andere hängen oder startet zur Unzeit neu.