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.
Dadurch schlägt aber der ökologische und ökonomische Wahnsinn der Sommerzeit (Energieeinsparung?) auch in der Datenverarbeitung zu. Für eine Stunde pro Jahr, nur bei der Umstellung von Sommerzeit auf Normalzeit (umgangssprachlich: 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!
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 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!
Bei nachträglich digitalisierten Daten (Fotos) ist oft die Uhrzeit nicht bekannt; dann ist es üblich, die Zeit mit 00:00:00 anzugeben. Liegt dieses Datum in der Sommerzeit, erhält die Datei eine falsche UTC, die zur Normalzeit mit Datum des Vortages um 23:00:00 angezeigt wird. Dateien deren Datum in der Sommerzeit liegt sollten immer mit 01:00:00 eingegeben werden. Es ist sogar zu überlegen, ob es nicht überhaupt sinnvoller wäre, statt 00:00:00 die Zeit 12:00:00 zu nehmen, da dann die statistische Abweichung zur tatsächlichen Zeit am geringsten ist. In dem Fall wäre für ein Datum zur Sommerzeit logischerweise 13:00:00 einzugeben. Meine Hoffnung ist, dass der Unsinn Sommerzeit eines Tages wieder abgeschafft wird (3/4 der Weltbevölkerung lebt ohne Sommerzeit) und das nicht nur wegen des hier geschilderten Problems.
Siehe auch: Beating the Daylight Savings Time bug