Findfirst/Findnext Sommer/Winterzeit

[zeras]

Wir haben folgendes Problem:
Während der Sommerzeit werden Dateien auf einen USB Stick kopiert und gleichzeitig in ein Zip Archiv gepackt.
Nun ist Winterzeit und es soll geprüft werden, ob sich die Daten auf dem USB Stick verändert haben. Es kann ja sein, dass jemand die Daten auf dem USB Stick verändert hat.
Als Routine nehme ich folgende:

Damit man sehen kann, welche Datei welches Datum hat, scanne ich jede Datei auf dem USB Stick in der Art:
FormatDateTime('dd/mm/yyyyy hh:nn', FileDateToDateTime(SR.Time));
Damit entsteht eine Stringliste, wo auch noch der jeweilige Dateiname mit hinterlegt ist.
Das gleiche mache ich mit den eingepackten Dateien. Diese packe ich aus und nutze dieselbe Routine. Die Infos stehen dann in einer 2. Stringliste. Die beiden Stringlisten vergleiche ich dann und es kommt nun immer 1 Stunde Unterschied bei allen Dateien raus.
Sollten nicht die Datumseinträge gleich sein, weil die Dateien an sich zur gleichen Zeit erstellt wurden?
Oder ist meine Denkweise hier nicht richtig?

[jbg]

Wenn der USB Stick mit FAT(Ex/32) formatiert ist, dann speichert er das Datum immer in der lokalen Uhrzeit (also Winterzeit oder Sommerzeit). Bei NTFS wird hingegen in UTC-Zeit (aka SystemTime) gepeichert und erst beim Einlesen an die lokale Uhrzeit angepasst, womit sich die Zeit der Datei bei der Umstellung automatisch ändert (so wird aus eine in Deutschland um 10:00 Uhr geschriebenen Datei schnell mal 4:00 Uhr wenn man in den USA ist)

Bei der ZIP-Datei hängt es vom Packer/Entpacker ab, ob er das Datum in lokaler Zeit und/oder UTC-Zeit abspeichert bzw. einliest.

[Dalai]

In Ergänzung zu jbg:
Wenn du zuverlässig Dateien vergleichen willst, ist sowas wie ein Zeitstempel ungeeignet, weil der von einer ganzen Reihe von Faktoren abhängt. Prüfsummen (SHA1, SHA256, notfalls auch MD5 etc) oder ein Vergleich nach Inhalt sind dafür besser geeignet. Klar ist das mehr Aufwand und setzt das Einlesen der kompletten Datei voraus, aber im Punkt "Sicherstellen, dass (k)ein Unterschied vorhanden ist" ist das unschlagbar.

MfG Dalai

[himitsu]

Zitat:

Zitat von Dalai (Beitrag 1279933)

ist sowas wie ein Zeitstempel ungeeignet, weil der von einer ganzen Reihe von Faktoren abhängt.

z.B. auch vom Datenformat, in welchem gespeichert wird.
Ältere FAT32 speicherten das Datum gern in einem Integer und waren dann nur bus zu einer ganzen Sekunde genau, NTFS speichert das Datum des letzten Zugriffs anders, als das Datum der Erstellung, bzw. der letzten Änderung, und die verschiedensten Archiv-Formate (ZIP usw.) machen es auch wieder anders,
womit es dort jeweis zu unterschiedlichen Rundungen kommt und man beim Vergleich garnicht "genau" auf Gleichheit prüfen sollte.

Und bezüglich dem "Datei(Inhalt) vergleichen" gibt es in der DP auch mehrere Threads.


Alternativ könntest du prüfen, ob das Dateidatum innerhalb der Sommerzeit liegt und dann die Stunde umrechnen.
Jeweils abhängig davon in welchem Format das Datum bei dir ankommt und wie es gespeichert wurde.

[zeras]

Danke für die Antworten.

Zitat:

Zitat von jbg (Beitrag 1279928)

Wenn der USB Stick mit FAT(Ex/32) formatiert ist.....

Ja.

Zitat:

Zitat von jbg (Beitrag 1279928)

Bei NTFS wird hingegen in UTC-Zeit (aka SystemTime) gepeichert und erst beim Einlesen an die lokale Uhrzeit angepasst

Unsere Server haben meines Wissen NTFS. So ergibt das auch ein Bild.

Jede Datei analysieren würde ich jetzt noch nicht favorisieren, aber vielleicht später.

Mich wundert es nur, dass die Kollegen das erst jetzt bemerkt haben, wo die Funktion schon seit Jahren so drin ist. Es müsste ja jedes Jahr mindestens 2x auftreten und da wir mehrere von den Sticks haben, sollte es ja schon vor Jahren so gewesen sein.

[himitsu]

Windows ohne Sommerzeit?

Oder Backup und Vergleich zufällig immer in der selben Zeitzone/Jahreszeit? (Sommerzeit oder Winterzeit)

[zeras]

Zitat:

Zitat von himitsu (Beitrag 1279961)

Windows ohne Sommerzeit?

Oder Backup und Vergleich zufällig immer in der selben Zeitzone/Jahreszeit? (Sommerzeit oder Winterzeit)

Sollte eigentlich nicht immer sein.
Zum Sachverhalt. Wir bauen Maschinen.
Beim Beginn der Prüfung der Maschinen wird der Stick erzeugt und das Zipfile dazu. Nach Ende der Prüfung wird dann die obige Prozedur gestartet, um festzustellen, ob jemand etwas geändert hat. Die Prüfung kann schon einige Tage bzw. Wochen dauern. Da sollte es mehr als einmal vorkommen, dass es in der Zeitzone 1 erstellt wird und dann in der Zeitzone 2 archiviert.
Ich werde mal die Kollegen fragen, warum das nicht eher aufgefallen ist.

[himitsu]

Problematisch werden solche Prozesse vorallem dann, wenn sie während der Zeitumstellung arbeiten, da es dann einmal im Jahr eine Stunde lang Zeiten doppelt gibt und ab der Umstellung die Zeiten dann auseinanderlaufen.
Ist fast so schlimm, wie der 2000er-Überlauf, aber praktisch passiert das selten, da um diese Zeit die Wenigsten arbeiten oder "problematische" Prozesse dort möglichst nicht durchführen.

[zeras]

Zitat:

Zitat von himitsu (Beitrag 1279969)

Problematisch werden solche Prozesse vorallem dann, wenn sie während der Zeitumstellung arbeiten, da es dann einmal im Jahr eine Stunde lang Zeiten doppelt gibt und ab der Umstellung die Zeiten dann auseinanderlaufen.
Ist fast so schlimm, wie der 2000er-Überlauf, aber praktisch passiert das selten, da um diese Zeit die Wenigsten arbeiten oder "problematische" Prozesse dort möglichst nicht durchführen.

Ja, am Sonntag Morgen um 2 Uhr wird bei uns keine neue Software erstellt. Das sollte eigentlich sicher sein. Aber vielleicht gibt es andere Firmen, wo das ein Problem darstellen kann.
Man kann gar nicht genug "Um die Ecke denken", um alle Eventualitäten zu ergründen.

[Luckie]

Automatischer Buildprocess? Bumm.