5
Sommerzeit, Winterzeit, völlig falsche Zeit (NTFS zu FAT bzw. FAT32 unter XP)
Ich suche noch eine Idee hinsichtlich der Problematik, dass die Dateizeiten von aufgenommenen Bildern, Diktaten und Faxen unter NTFS aktuell, also in der Sommerzeit, „falsch“ sind, wenn die Dateien in der Winterzeit angelegt wurden.
Ich führe ein Fahrtenbuch z. B. so, dass ich die Fahrtzeitpunkte nur diktiere und diese Diktatddateien dann auf den Rechner überspiele. Die Auswertung dieser Dateien erfolgt irgendwann später und unterstellt dann, dass Dateidatum und -uhrzeit richtig sein müssen, weil ich diese nicht explizit diktiere! Ich verlasse mich somit darauf, dass die Zeiten stimmen.
Es ist extrem problematisch, wenn aktuell eine Diktatdatei aus der Winterzeit unter NTFS um eine Stunde falsch dargestellt wird, nur weil wir mittlerweile Sommerzeit haben.
Unter FAT32 stellt sich das Problem nicht, da dort ja immer die Lokalzeit die Speicherzeit ist, während es unter NTFS die UTC-Zeit ist, welche dann beim Lesen und Anzeigen in Relation zur aktuellen Sommer-/Winterzeit „interpretiert“ wird!
Hat jemand eine Idee, wie man XP irgendwie ‚überreden’ kann, auch unter NTFS immer Lokalzeit zu schreiben und anzuzeigen?
Ich habe das hier in ‚Netzwerk’ geschrieben, weil gerade beim syncen über das Netzwerk die „falschen“ NTFS-Zeiten die neueren sind und wenn man zwischen FAT32 und NTFS abgleicht, würden genau diese falschen NTFS-Zeiten zur Quelle werden und die Dateien mit den „guten“ und richtigen FAT32-Zeiten überschreiben. Aktuell in der Sommerzeit sind alle Dateien auf FAT32 mit der richtigen Zeit eine Stunde älter als die entsprechende NTFS-Datei!
Ich führe ein Fahrtenbuch z. B. so, dass ich die Fahrtzeitpunkte nur diktiere und diese Diktatddateien dann auf den Rechner überspiele. Die Auswertung dieser Dateien erfolgt irgendwann später und unterstellt dann, dass Dateidatum und -uhrzeit richtig sein müssen, weil ich diese nicht explizit diktiere! Ich verlasse mich somit darauf, dass die Zeiten stimmen.
Es ist extrem problematisch, wenn aktuell eine Diktatdatei aus der Winterzeit unter NTFS um eine Stunde falsch dargestellt wird, nur weil wir mittlerweile Sommerzeit haben.
Unter FAT32 stellt sich das Problem nicht, da dort ja immer die Lokalzeit die Speicherzeit ist, während es unter NTFS die UTC-Zeit ist, welche dann beim Lesen und Anzeigen in Relation zur aktuellen Sommer-/Winterzeit „interpretiert“ wird!
Hat jemand eine Idee, wie man XP irgendwie ‚überreden’ kann, auch unter NTFS immer Lokalzeit zu schreiben und anzuzeigen?
Ich habe das hier in ‚Netzwerk’ geschrieben, weil gerade beim syncen über das Netzwerk die „falschen“ NTFS-Zeiten die neueren sind und wenn man zwischen FAT32 und NTFS abgleicht, würden genau diese falschen NTFS-Zeiten zur Quelle werden und die Dateien mit den „guten“ und richtigen FAT32-Zeiten überschreiben. Aktuell in der Sommerzeit sind alle Dateien auf FAT32 mit der richtigen Zeit eine Stunde älter als die entsprechende NTFS-Datei!
Share on Facebook
Share on Twitter
Share on Reddit
Share on LinkedinPlease also mark the comments that contributed to the solution of the article
Content-Key: 84580
Url: https://administrator.de/contentid/84580
Printed on: April 25, 2024 at 10:04 o'clock
5 Comments
Latest comment
Das ist Unsinn das das UTC Zeit ist ! Wie kommst du darauf ???
Wenn du unten in der Taskleiste die Uhrzeit doppelklickst, dann im aufpoppenden Window den Karteireiter "Internetzeit" wählst, dort den Haken setzt "Automatisch mit dem Internetzeitserver synchronisieren" und dann als Server die Physikalisch Technische Bundesanstalt (PTB) wählst, die in Deutschland die amtliche Zeit propagiert, dann hast du immer die aktuelle Zeit auf dem Rechner, egal ob Sommer oder Winter !!
Die Zeitserver Adressen der PTB findest du hier:
http://www.ptb.de/de/org/q/q4/q42/ntp/ntp_main.htm
Es reicht für die Synchronisation wenn du nur alle paar Tage mal im Internet bist...
Wenn du unten in der Taskleiste die Uhrzeit doppelklickst, dann im aufpoppenden Window den Karteireiter "Internetzeit" wählst, dort den Haken setzt "Automatisch mit dem Internetzeitserver synchronisieren" und dann als Server die Physikalisch Technische Bundesanstalt (PTB) wählst, die in Deutschland die amtliche Zeit propagiert, dann hast du immer die aktuelle Zeit auf dem Rechner, egal ob Sommer oder Winter !!
Die Zeitserver Adressen der PTB findest du hier:
http://www.ptb.de/de/org/q/q4/q42/ntp/ntp_main.htm
Es reicht für die Synchronisation wenn du nur alle paar Tage mal im Internet bist...
Das ist Unsinn das das UTC Zeit ist ! Wie kommst du darauf ???
Sicher war es schwierig, das richtig zu verstehen, weil es mir nicht leicht fiel, es mit wenigen Worten zu erklären und in Foren werden immer nur „wenige Worte“ gelesen.
Also, auf NTFS wird immer UTC geSPEICHERt. Das LIEFERN (Anzeigen) des Dateizeitpunktes als Lokalzeit erledigt dann XP in Abhängigkeit der Zeitzone (z. B. GMT+1) des Rechners und der aktuellen Sommer- oder Winterzeit. Verdeutlichen kann man das besser mit konkreten Beispielen, hier mit dem Unabhängigkeitstag 4. Juli und Heiligabend:
1. Lege eine mit FAT-formatierte Diskette ins Laufwerk A:
2. Stelle Deine Uhr auf den 04.07 2007, 18:00 Uhr zurück (das ist Sommerzeit)
3. Lege Datei '04.07.2007,1800.txt' auf A:\ (=FAT) und C:\ (=NTFS) an
4. Stelle Deine Uhr auf den 24.12 2007, 18:00 Uhr (das ist bereits Winterzeit)
5. Lege Datei '24.12.2007,1800.txt' auf A:\ und C:\ an
6. Stelle Deine Uhr auf Heute zurück
Ergebnis:
C:\04.07.2007,1800.txt 18:00
A:\04.07.2007,1800.txt 18:00
C:\24.12.2007,1800.txt 19:00 falsch!
A:\24.12.2007,1800.txt 18:00
Auf A:\ haben beide Dateien 18:00 Uhr, so wie ich/man sich das hier wünschen und erwarten würde. Auf C:\ hat ‚24.12.2007,1800.txt‘ aber 19:00 Uhr, weil wir uns aktuell in der Sommerzeit befinden. Ab der kommenen Winterzeit würde diese Zeit unter NTFS dann auch wieder auf 18:00 Uhr lauten, aber dann wird C:\04.07.2007,1800.txt‘ falsch sein. Dies bedeutet ganz allgemein für (ein paar Millionen) XP-User bei NTFS-Laufwerken auf der ganzen Welt):
Alle Dateizeiten, die in der Winterzeit ENTSTANDEN, aber in der Sommerzeit geLIEFERt werden müssen, sind um eine Stunde falsch!
Alle Dateizeiten, die in der Sommerzeit ENTSTANDEN, aber in der Winterzeit geLIERFERt werden müssen, sind um eine Stunde falsch!
Noch allgemeiner: Unter XP und NTFS funktioniert das Liefern der richtigen Lokalzeit nur in gleichen Sommer-/Winterzeiten!
Wer obiges Beispiel mit C:\ und A:\ nicht nachvollziehen will oder kann (mangelnde Rechte zur Zeitumstellung), mag sich heute, Sommerzeit, mal JPGs aus der vergangenen Sommer- und Winterzeit anschauen und dabei im Explorer das Ansichtsdetail „Bild aufgenommen am“ einschalten. Dort werden die EXIF-Infos der JPGs ausgewertet und dort sind meines Wissens immer echte und richtige lokale Aufnahmezeiten gespeichert. Dort sieht man bei seinen Weihnachtsbildern (Winterzeit) eine Differenz von einer Stunde, während Bilder von Grillabenden keine Unterschiede aufweisen, weil sie in der Sommerzeit aufgenommen wurden und wir gerade wieder Sommerzeit haben!
Richtig lustig wird es, wenn man jetzt in Sydney wäre und seinen Laptop korrekt auf GMT+10 stellt. Schaut man sich dann seine Weihnachtsbilder an, dann sind die angeblich mitten in der Nacht aufgenommen worden!
Unter FAT32 gibts das alles nicht. Dort wird der lokale Erstellzeitpunkt gespeichert und jedes mir bekannte MS-BS gibt diesen Zeitpunkt dann genau so (uninterpretiert) wieder, wie er ist und war! Egal, WO (Zeitzone) man sich befindet und egal, ob Sommer- oder Winterzeit ist!
Das ist das Problem und ich weiß nicht, ob es einen Trick/Einstellung gibt, wie XP immer die *für mich* richtigen Aufnahmezeiten von Dateien auch unter NTFS wiedergeben kann!
Es ist bedauerlich, wenn aqui, der die Problematik nicht verstanden hat, von "Unsinn" schreibt. Ich suche auch noch eine Lösung, solange Microsoft nicht bereit ist, seinen Fehler zu korrigieren:
Im FAT-Dateisystem ist das Datum und die Uhrzeit der Speicherung einer Datei die lokale Zeit des Rechners. Egal wann und wo ich die Datei ansehe bleiben Datum und Uhrzeit unverändert. Damit ist es aber nicht möglich, Dateien über Zeitzonen hinweg abzugleichen.
Es war also eine logisch richtige Entscheidung, bei NTFS Datum und Zeit in UTC (Universal Time Coordinated) abzuspeichern, damit weltweit Dateien auf Gleichzeitigkeit bzw. chronologische Reihenfolge untersucht werden können.
Jetzt schlägt aber der Wahnsinn der Sommerzeit auch in der Datenverarbeitung zu. Für eine Stunde pro Jahr nur bei der Umstellung von Sommer- auf Winterzeit entsteht bei der angezeigten lokalen Zeit eine Doppeldeutigkeit. Am letzten Sonntag im Oktober ergäbe UTC 00:30 die MESZ 02:30 und UTC 01:30 die MEZ 02:30!
Das würde trotz fehlender Angabe von MESZ/MEZ kein Problem hervorrufen, solange dies nur eine Anzeige wäre aber die interne Verarbeitung konsequent in UTC ablaufen würde.
Leider erfolgt die interne Verarbeitung in lokaler Zeit. Um die bei dieser Vorgehensweise entstehende Doppeldeutigkeit (für nur eine Stunde im Jahr) zu vermeiden, kam Microsoft auf die Wahnsinnsidee, Datum und Zeit einer Datei immer in die gerade gültige Sommer- bzw. Winter- Zeit umzurechnen.
Im Sommer erzeugte Dateien werden im Winter um eine Stunde falsch angezeigt, im Winter erzeugte Dateien werden im Sommer um eine Stunde falsch angezeigt. Dateien aus Zeitzonen, die keine Sommerzeit kennen, werden bei uns im Sommer immer um eine Stunde falsch angezeigt.
Einzig richtig wäre es wie gesagt, die Verarbeitung ausschließlich nach UTC abzuwickeln und nur für die Anzeige in die lokale Zeit umzurechnen ggf. ergänzt um das "S" für Sommerzeit. Dateien, die in anderen Zeitzonen erzeugt sind würden dabei auch immer richtig angezeigt werden, allerdings in der lokalen Zeit des verarbeitenden Rechners.
Etwas anders verhält es sich mit Fotodateien. Diese werden wie bei FAT in der lokalen Zeit der Kamera gespeichert. Das ist so lange brauchbar, wie mich nur die lokale Zeit der Aufnahme interessiert, was auch meist der Fall ist. Bei der chronologischen Wiedergabe von Bildern kann dann aber folgendes Problem entstehen:
Beim Flug von Frankreich nach England werden die Fotos bei der Ankunft noch vor den Fotos beim Abflug gezeigt, weil ich über dem Ärmelkanal die Zeit der Kamera korrigiert habe. Noch gravierender ist dies beim Flug von Neuseeland zu den Cook-Inseln. Da werden die Fotos bei der Ankunft auf Rarotonga einen Tag vor dem Abflug in Auckland gezeigt.
Auch hier wäre es richtiger, die Dateien der Bilder in UTC zu speichern. Dazu müsste die Kamera die Möglichkeit der Zeitzoneneinstellung bieten. Die EXIF-Daten könnten dann die lokale Zeit zeigen, die Dateien würden aber per UTC chronologisch in richtiger Reihenfolge bleiben.
Beim Überspielen von FAT bzw. Kamera zu NTFS wird Datum und Zeit in die richtige UTC umgerechnet. Beim umgekehrten Weg von NTFS zu FAT bzw. Kamera wird der Datei eine um eine Stunde falsche Zeit mitgegeben, wenn Aufnahme und Überspielung nicht in der selben Winter- bzw. Sommer- Zeit liegen!
Zur Zeit müssen wir leider damit leben, dass in Windows Datum und Zeit einer "NTFS-Sommerdatei" im Winter und einer "NTFS-Winterdatei" im Sommer um eine Stunde falsch angezeigt werden, weil in der Verarbeitung nicht der konsequente Schritt von lokaler Zeit zu UTC vollzogen wurde.
Siehe auch:
http://www.codeproject.com/KB/datetime/dstbugs.aspx
Im FAT-Dateisystem ist das Datum und die Uhrzeit der Speicherung einer Datei die lokale Zeit des Rechners. Egal wann und wo ich die Datei ansehe bleiben Datum und Uhrzeit unverändert. Damit ist es aber nicht möglich, Dateien über Zeitzonen hinweg abzugleichen.
Es war also eine logisch richtige Entscheidung, bei NTFS Datum und Zeit in UTC (Universal Time Coordinated) abzuspeichern, damit weltweit Dateien auf Gleichzeitigkeit bzw. chronologische Reihenfolge untersucht werden können.
Jetzt schlägt aber der Wahnsinn der Sommerzeit auch in der Datenverarbeitung zu. Für eine Stunde pro Jahr nur bei der Umstellung von Sommer- auf Winterzeit entsteht bei der angezeigten lokalen Zeit eine Doppeldeutigkeit. Am letzten Sonntag im Oktober ergäbe UTC 00:30 die MESZ 02:30 und UTC 01:30 die MEZ 02:30!
Das würde trotz fehlender Angabe von MESZ/MEZ kein Problem hervorrufen, solange dies nur eine Anzeige wäre aber die interne Verarbeitung konsequent in UTC ablaufen würde.
Leider erfolgt die interne Verarbeitung in lokaler Zeit. Um die bei dieser Vorgehensweise entstehende Doppeldeutigkeit (für nur eine Stunde im Jahr) zu vermeiden, kam Microsoft auf die Wahnsinnsidee, Datum und Zeit einer Datei immer in die gerade gültige Sommer- bzw. Winter- Zeit umzurechnen.
Im Sommer erzeugte Dateien werden im Winter um eine Stunde falsch angezeigt, im Winter erzeugte Dateien werden im Sommer um eine Stunde falsch angezeigt. Dateien aus Zeitzonen, die keine Sommerzeit kennen, werden bei uns im Sommer immer um eine Stunde falsch angezeigt.
Einzig richtig wäre es wie gesagt, die Verarbeitung ausschließlich nach UTC abzuwickeln und nur für die Anzeige in die lokale Zeit umzurechnen ggf. ergänzt um das "S" für Sommerzeit. Dateien, die in anderen Zeitzonen erzeugt sind würden dabei auch immer richtig angezeigt werden, allerdings in der lokalen Zeit des verarbeitenden Rechners.
Etwas anders verhält es sich mit Fotodateien. Diese werden wie bei FAT in der lokalen Zeit der Kamera gespeichert. Das ist so lange brauchbar, wie mich nur die lokale Zeit der Aufnahme interessiert, was auch meist der Fall ist. Bei der chronologischen Wiedergabe von Bildern kann dann aber folgendes Problem entstehen:
Beim Flug von Frankreich nach England werden die Fotos bei der Ankunft noch vor den Fotos beim Abflug gezeigt, weil ich über dem Ärmelkanal die Zeit der Kamera korrigiert habe. Noch gravierender ist dies beim Flug von Neuseeland zu den Cook-Inseln. Da werden die Fotos bei der Ankunft auf Rarotonga einen Tag vor dem Abflug in Auckland gezeigt.
Auch hier wäre es richtiger, die Dateien der Bilder in UTC zu speichern. Dazu müsste die Kamera die Möglichkeit der Zeitzoneneinstellung bieten. Die EXIF-Daten könnten dann die lokale Zeit zeigen, die Dateien würden aber per UTC chronologisch in richtiger Reihenfolge bleiben.
Beim Überspielen von FAT bzw. Kamera zu NTFS wird Datum und Zeit in die richtige UTC umgerechnet. Beim umgekehrten Weg von NTFS zu FAT bzw. Kamera wird der Datei eine um eine Stunde falsche Zeit mitgegeben, wenn Aufnahme und Überspielung nicht in der selben Winter- bzw. Sommer- Zeit liegen!
Zur Zeit müssen wir leider damit leben, dass in Windows Datum und Zeit einer "NTFS-Sommerdatei" im Winter und einer "NTFS-Winterdatei" im Sommer um eine Stunde falsch angezeigt werden, weil in der Verarbeitung nicht der konsequente Schritt von lokaler Zeit zu UTC vollzogen wurde.
Siehe auch:
http://www.codeproject.com/KB/datetime/dstbugs.aspx
Hallo Blue,
vielen Dank dafür, daß Du nach solanger Zeit zu meinem Problem noch Stellung nimmst!
Ich habe das Problem mit meinen Diktaten jetzt dahingehend "gelöst", daß ich die Dateien jeweils Stunden vor einem Zeitwechsel mit WinRar einzippe, denn in Achiven hat alles fehlerhafte ein Ende. Dort wird Lokalzeit gespeichert, das habe ich getestet.
vielen Dank dafür, daß Du nach solanger Zeit zu meinem Problem noch Stellung nimmst!
Ich habe das Problem mit meinen Diktaten jetzt dahingehend "gelöst", daß ich die Dateien jeweils Stunden vor einem Zeitwechsel mit WinRar einzippe, denn in Achiven hat alles fehlerhafte ein Ende. Dort wird Lokalzeit gespeichert, das habe ich getestet.
Es ist "schön" zu sehen, dass doch Leute gibt die damit eine Problem haben. Habe immer gedacht wir wären die einzigen. Wir schlüsseln die Version unserer Software in der Datei-Urzeit auf. Hat bis Windows 98 gut geklappt, aber bei W2k kamen dann die Probleme. Besonderst in einem Bunten Netzwerk mit W98, W2k und W2k3 Server.
Haben die Sommerzeit auf allen PCs deaktiviert. seit dem ist alles o.k.
Haben die Sommerzeit auf allen PCs deaktiviert. seit dem ist alles o.k.
