[gelöst]Claws-mail und pugin-claws-archiver

[schwedenmann]

Hallo

ich versuche jetzt seit 2 Tagen, mit dem plugin claws-archiver (oder nur archiver archiver) einige maisl von mir zu archivieren. Das plugin hat als letzte Option das Setzen eines Datums, umd alle mails vor diesem Datum fürs Archiv zu erfassen. Egal was und wie ich das Datum z.B. 1.1.2018 12.31.2017 um alle mails vor diesen Daten zu erfassen, es kommt immer eine Fehlermeldung

Fehler beim Erstellen des Archivs:
No files for archiving

mit hoher Aussagekraft

Natürlich gibt es mails vor dem 1.1.2018

Lasse ich das Datum weg, wird ein Archiv des gesamten ausgewählten mailordners erstellt. Das ist zwar auch nett, ich benötige jedoch mails bis incl. 2017 um sie zu archivieren und dann im mailordner zu entsorgen.
Hat jemand hier im DF diese plugin im Einsatz ?

mfg
schwedenmann

[Blackbox]

Das amerikanische Datumsformat 2018-01-01 hast du wohl noch nicht versucht, oder?
Nicht schön, ich weiß, aber manche Anwendung besteht darauf.

[hikaru]

Claws-Mail selbst orientiert sich beim Datumsformat standardmäßig an der gesetzten Locale. Das Plugin kenne ich allerdings nicht.

Das amerikanische Datumsformat 2018-01-01 hast du wohl noch nicht versucht, oder?
Nicht schön, ich weiß, aber manche Anwendung besteht darauf.

Vorsicht! Das könnte missverständlich formuliert sein.
Dein Datumsstring ist ISO-8601-formatiert (Bindestriche: YYYY-MM-DD). "Amerikanisches Datumsformat" könnte allerdings das "bürgerliche" Format YYYY/DD/MM meinen (sollte dann aber Slashes haben).
Am 1. Januar ist das egal und am heutigen 16. Januar wird es aus dem Kontext klar, weil es keinn 16. Monat gibt. Aber z.B. am 10. Januar ist eine eindeutige Benennung bzw. Formatierung wichtig, um ihn vom 1. Oktober unterscheiden zu können.

[pferdefreund]

Wir haben doch hier open-source Software - Quelltext runterladen, nachschauen und entsprechend eingeben. Ist doch kein Outlook.

[Blackbox]

Vorsicht! Das könnte missverständlich formuliert sein.
Dein Datumsstring ist ISO-8601-formatiert (Bindestriche: YYYY-MM-DD). "Amerikanisches Datumsformat" könnte allerdings das "bürgerliche" Format YYYY/DD/MM meinen (sollte dann aber Slashes haben).
Am 1. Januar ist das egal und am heutigen 16. Januar wird es aus dem Kontext klar, weil es keinn 16. Monat gibt. Aber z.B. am 10. Januar ist eine eindeutige Benennung bzw. Formatierung wichtig, um ihn vom 1. Oktober unterscheiden zu können.

Recht hast du, es war einfach schon zu spät für meine Antwort.
Aber du hast es ja richtig ausformuliert.
Danke dafür!

[schwedenmann]

Hallo

Für alle die dieses plugin nutzen wollen, Format ist folgemdermaßen einzutragen, ohne ' oder "


Format ist YYYY-MM-DD

also z.B. 2017-12-31 oder 2018-01-01

mfg
schwedenmann

[fischig]

Das erste Beispiel entspricht mit Sicherheit nicht dem Format YYYY-DD-MM. Warum du das zweite (uneindeutige Beispiel) nach hikarus Hinweis überhaupt noch mal benutzt, verstehe ich auch nicht.

[schwedenmann]

Hallo

Das erste Beispiel entspricht mit Sicherheit nicht dem Format YYYY-DD-MM.

Richtig

YYYY-MM-DD ist richtig

beim zweiten beispiel würde ich,da kein IT-ler immer nocjh YYYY-1-1 schreiben

mfg
schwedenmann

[fischig]

https://de.wikipedia.org/wiki/%C3%9Cber ... beim_Reden

[hikaru]

Halb-OT:

beim zweiten beispiel würde ich,da kein IT-ler immer nocjh YYYY-1-1 schreiben

Vorsicht! Das könnnte zu einer Sicherheitslücke führen.
Wenn du einen so formatierten Datumsstring händisch aufschreibst, ausdruckst oder in anderer editierbarer Form weitergibst, dann könnte ein anderer daraus durch geschicktes Anhängen einer Ziffer jedes beliebige Datum zwischen dem 10. und 19. Januar machen.

Das mag etwa konstruiert klingen, daher aus aktuellem Anlass ein ähnliches praxisnäheres Beispiel:
Das aktuelle Jahr 2020 sollte man in Big-Endian-Formatierungen nicht abkürzen (z.B. unser bürgerliches DD.MM.YY[YY])! Aus DD.MM.20 lässt sich nämlich durch Anhängen von zwei Ziffern jedes beliebige Jahr zwischen 2000 und 2099 machen. Bei Dokumenten mit Vertragscharakter kann das zu bösen Überraschungen führen.

Edit:
Streng genomen sollte man aus dem gleichen Grund in Big-Endian-Formatierungen den Tag grundsätzlich zweistellig, notfalls mit führender Null schreiben, um nicht z.B. aus dem 1. Januar den 11. Januar machen zu können.
Auch auf die verkürzte ISO-8601-Schreibweise (YY-MM-DD) sollte man vorsichtig einsetzen, um Jahrhundertverschiebungen auszuschließen.