Gut beobachtet, Richard. Den Tag der Arbeit habe ich als Test dabei 😃 - wenn intern die defaults Einstellungen für AppleICUDateFormatStrings verstellt sind, sehe ich für den 1. Mai ein Datum in einem anderen Monat und weiß, das ich den Daten für die beweglichen Feiertage nicht trauen sollte, beispielsweise, wenn ich das Datumsformat umgestellt habe, so dass die Reihenfolge yyyy-mm-dd ist.
Ich liebe Apple Skript, aber das Arbeiten mit Objekten der Klasse Date ist riskant. Es fehlt ein Konstruktor, mit dem man sicher im Code ein bestimmtes Datum eingeben kann, das nicht von den Systemeinstellungen für die Region und Sprache abhängig ist. Wenn wir ein Datumsobjekt erzeugen, muss es über einen Date String initialisiert werden. Das Format für den Date String hängt von der Region ab, in der wir das Skript schreiben. Wenn ich ein Skript schreibe, werden beim ersten Öffnen die Datumsstrings meiner Region angepasst. Es ist schwer, ein Skript für Kalenderdaten zu schreiben, dass sowohl in den USA als auch in Deutschland mit den gängigen Landeseinstellungen läuft.
Ein Beispiel: Ich stelle in den Systemeinstellungen > Allgemein > Sprache und Region das Datumsformat 2025-08-19 (yyyy-mm-dd) ein. (Das verwende ich gerne, um das Datum beim Export in die Dateinamen von Fotos zu schreiben).

Wenn ich jetzt im Skript Editor das Datum für den 1.5.2000 als Date String eingebe, wie hier:

dann wird beim ersten Ausführen der String in ein einheitliches Format, aber mit falschem Datum gewandelt:

Deshalb meine Warnung, nur die voreingestellten Datumsformate zu verwenden.
Und ich schreibe in jedes Skript, das mit Datumsangaben rechnet, lieber auch in Testdatum rein, bei dem ich auf den ersten Blick erkenne, ob das Datum korrekt ist.
Und unabhängig vom Test sehe ich nebenbei auch, auf welchen Wochentag der 1.5. fällt.