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.

[Dejan Vu]

Zitat:

Zitat von Luckie (Beitrag 1279983)

Automatischer Buildprocess? Bumm.

Erklär mal, wie das bei Steuerungsprogrammierung funktionieren soll. Die Maschinen werden -zumindest da, wo ich bisher gearbeitet habe, erst beim Kunden fertig programmiert, zum größten Teil ohne Internetverbindung.

Wir haben das aber so gelöst, das die Programmierer gehalten waren, den aktuellen Stand mindestens zum Freitag zu sichern, bei Hotfixes jedoch täglich zum Feierabend (wie man das eben einrichten kann).

Bei Großprojekten wurde eine Art SVN beim Kunden eingerichtet, ansonsten wurde der aktuelle Stand auf dem Heimserver eingelagert.

[Luckie]

Ok, so genau hast du es ja nicht erläutert. Aber so etwas ware eben was, was automtisch angestoßen wird.

[zeras]

Ich komme noch einmal auf das Thema zurück, da ich mein Programm derzeit ein wenig anpassen muss. Da stellt sich mir die Frage, wer die Uhrzeit überhaupt richtig anzeigt.
Das alles unter Windows 7 bezieht sich auf eine Datei auf einem FAT16 USB Stick.
Wenn ich beispielsweise ein DOS Fenster aufmache, steht als Uhrzeit 07:44 drin, wenn ich das gleiche im Explorer oder SpeedCommander anzeigt, wird als Uhrzeit 08:44 angezeigt. Was ist da nun richtig?

[himitsu]

Das weiß niemand?

Der FAT-Filesystemdriver speichert das Datum als Local Time.
Im NTFS wird es als UTC gespeichert.

Vor allem beim FAT mußt du also auch beachten wann das Datum ist und ob die Sommer-/Winterzeit sich zwischendurch geändert hat.
Schlimmer wird es, wenn die Datei/USB-Stick von verschiedenen Rechnern kommt, mit unterschiedlichen Zeitzonen, denn das kann garnicht erkannt werden.

Teilweise passt der Treiber das Datum an,
manchmal die Programme.

Tipp: Speichere mal mit dem Notepad eine Datei, dann verleiche das Datum.
Und mache in der Konsole (nein, das ist kein DOS) ein

Delphi-Quellcode:

ECHO a > test.txt

und vergleiche ebenfalls das Datum.
> Aktuelle Uhzeit, Zeit vom DIR und vom Explorer

[zeras]

Zitat:

Zitat von himitsu (Beitrag 1386454)

Delphi-Quellcode:

ECHO a > test.txt

Was soll das machen? Da passiert bei mir nichts.

Ich habe eine neue Datei auf dem USB Stick erstellt. Zeit 21:57 in der Konsole und auch im Explorer.

[himitsu]

Es erstellt eine Datei im aktuellen Arbeitsverzeichnis?

[Luckie]

Mit FAT hast du verloren, würde ich sagen. Denn dann müsstest du wissen wo der Rechner zum Zeitpunkt des Speicherns gestanden hat und wann die Datei gespeichert wurde. Bei NTFS ist es einfach, da, wie schon gesagt UTC (Oder um die Navi CIS Fans zu erfreuen) Zulu Time benutzt wird. ;-)

[p80286]

Nachdem ich vor kurzem bemerkt habe, das die Kopien der Dateien von meinem Arbeitsplatzrechner auf dem Fileserver einen um 1 Stunde differierenden Zeitstempel anzeigen, ist es mir in der Zwischenzeit s...egal wenn das Dateidatum um exakt eine Stunde differiert. Vor 10-15 Jahren konnte man noch Sommer/Winterzeit als Ausrede benutzen, heute halte ich das für ein Armutszeugnis.

Gruß
K-H

[himitsu]

Zitat:

Zitat von p80286 (Beitrag 1386463)

Vor 10-15 Jahren konnte man noch Sommer/Winterzeit als Ausrede benutzen, heute halte ich das für ein Armutszeugnis.

Darum wurde der Fehler ja im NTFS ausgebessert :zwinker:
und nebenbei auch die Auflösung der Zeit verfeinert.

[zeras]

Zitat:

Zitat von Luckie (Beitrag 1386462)

Mit FAT hast du verloren, würde ich sagen. Denn dann müsstest du wissen wo der Rechner zum Zeitpunkt des Speicherns gestanden hat und wann die Datei gespeichert wurde. Bei NTFS ist es einfach, da, wie schon gesagt UTC (Oder um die Navi CIS Fans zu erfreuen) Zulu Time benutzt wird. ;-)

Die Dateien werden bei uns immer in einer Firma erzeugt und gespeichert. Immer Thüringen :-)
Deshalb frage ich mich, warum hier UTC eine Rolle spielen sollte.

Wird denn bei NTFS die Uhrzeit in UTC gespeichert und dann anhand der Location des Rechners auf lokale Zeit umgerechnet?

[DeddyH]

Zitat:

Zitat von zeras (Beitrag 1386473)

Wird denn bei NTFS die Uhrzeit in UTC gespeichert und dann anhand der Location des Rechners auf lokale Zeit umgerechnet?

AFAIK ja: FileTimeToLocalFileTime