Tweet
Was kommt denn bei Dir bei http://miniserver.ip/dev/cfg/timezoneoffset
Das sollte eigentlich passen.
Backup habe ich noch nicht probiert, aber für mich sieht das so aus als speichern die gar keine richtigen Daten für die Files
und das ALLE Statistiken am Ende des Monats Punkt 0:00 Uhr geschrieben werden, glaube ich nicht. Ich glaube, dass die einfache nur 0:00 Uhr am 1. des Folgemonat annehmen und angeben.
Das ist mit Sicherheit nicht das reale Modified Datum der Daten.
Und ein FTP Server ist das auf dem MSv1 auch nicht. Das ist irgend etwas quick & dirty zusammengebasteltes. Das kann nur cd und list. Da geht noch nicht einmal quit, bye oder sonstige Standard Kommandos.
Und es ist auch richtig, dass bei LIST ein Format kommt, was human readable sein soll, aber das ist es ja auch nicht, da auch ich als Mensch nicht das richtige Datum ermitteln kann.
Wie Du selbst schon gesagt hast, kann man in dem Loxone-Fall eben nicht nur ein Jahr abziehen, weil das dann 26 z.B. tatsächlich wieder nicht funktionieren würde.
Das Problem bei Dir ist, dass es da irgendeine Verschiebung in der TZ gibt. Ich habe auch Berlin MEZ und beim mir kommt 1.3. 00:00Uhr zurück. Wenn Du sagst, dass das jetzt bei Dir bei den neueren Files richtig ist, dann gehe ich mal davon aus, dass es da in einer FW mal einen TZ Fehler gab.
"Nur" alle anderen Statistikdaten haben das Problem. Das müsstest Du auch sehen können, wenn Du Dir eine Datei OHNE "_[1-9]" anschaust. Sowohl beim Download, als auch in Loxone Config sehe ich dann 23:00 bzw. während der Sommerzeit 22:00 Uhr als Zeitstempel. Die haben bei Dir wahrscheinlich noch alle 2025 im Jahr. In Loxone Config im Menü "SD-Karte verwalten" kann man das gut erkennen. Die Zeitstempel für die Dateien aus 2024 haben noch im Nov und Dez diese Zeitangaben bis 23 Uhr und mein letztes Update ist deutlich länger her.
Ich glaube daher, dass die älteren Formate für Statistikdateien nicht um 00:00 Uhr UTC, sondern um 00:00 Uhr MEZ auf den nächsten Monat wechseln. Das würde bedeuten, dass die dort vorhandenen Zeitstempel nicht in UTC, sondern lokaler Zeit des MS gespeichert werden. Überprüfen werde ich das am Monatsende (wenn ich es nicht vergesse) und so lange wach bin
.
Das Dateien immer als neuer gekennzeichnet wurden, kann auch behoben sein. Das habe ich ja auch optimiert. Nach aktuellem Release war es ja so, dass das Datum IMMER im aktuellen Jahr ist. Beispiel … Datei Dez 15 10:20 wird im Januar 2025 als 15.12.2025 geparst. Das ist ja definitiv falsch und daher am Windows ja noch 11 Monate lang neuer als now ;-). Das habe ich ja geändert. Es gibt hier keine Datum mehr, was neuer als now ist. Daher kann es sein, dass das Problem behoben ist …
Code:
if (dateTime >= DateTime.Now)
{
//filedate newer than now is not possible ... date from the last year
dateTime.AddYears(-1);
}
Wenn man das Jahr richtig machen wollte, müsste man jetzt prüfen ob es das Standard Datum ist. Wenn ja, dann das Jahr aus dem Dateinamen. Ist es ein Zufallsdatum, wurde die Datei wohl innerhalb des letzten Jahres geändert, dann nach meiner Methode vorgehen.
Ich glaube, dass ist für den Zweck alles zu aufwendig und ich sollte beim 29.2. nicht mehr das vorherige Jahr nehmen, sondern einfach den 1.03. und das Jahr nach meiner Berechnung, dann sollte es keine Fehler mehr geben.
Wie kommst Du eigentlich drauf, dass beim Backup das Datum richtig ist? Ich habe mal ein Backup gemacht, das bekommen alle Dateien für created, modified und accessed das aktuelle Datum.
Ja, es ist schon wirklich schlimm wie halbherzig viele Dinge bei Loxone programmiert sind und man immer wieder WA‘s erstellen muss … Aber hey, wollen wir uns mal nicht beschweren, die Software ist ja kostenlos
So viel Forschungsarbeit habe ich nur deshalb in das Thema gesteckt, weil ich die alten Statistiken meiner Zähler konvertieren möchte. Das das ingesamt so kompliziert wird, hätte ich vorher nie vermutet.
Ich habe alle Änderungen von mir auf Github bereitgestellt: https://github.com/Jan21493/Loxone_L...s/tag/v1.0.6.0
Kommentar