![]() |
Irritationen bei SetLastWriteTime/ GetLastWriteTime
Hallo zusammen,
ich habe ein bisschen mit TFile.SetLastWriteTime und TFile.GetLastWriteTime herumprobiert. Dabei sind mir zwei Dinge aufgefallen, die ich mir nicht erklären kann: 1.
Delphi-Quellcode:
TFile.SetLastWriteTime('test.txt', StrToDateTime('01.05.2020 10:00'));
Der Windows-Explorer zeigt für die Datei jetzt 01.05.2020 11:00 an. Hängt wohl mit der Sommerzeit zusammen. Bei Tagen außerhalb der Sommerzeit stimmt die Uhrzeit überein. 2. die UTC-Variaante:
Delphi-Quellcode:
Wieso 09:00, wo ist die Stunde geblieben? Sollte da nicht nach Set... und Get.. wieder das selbe rauskommen?
TFile.SetLastWriteTimeUTC('test.txt', StrToDateTime('01.05.2020 10:00'));
ShowMessage(DateTimeToStr(TFile.GetLastWriteTimeUTC('test.txt'))); // zeigt 01.05.2020 09:00 Passiert auch nur bei Daten innerhalb der Sommerzeit. |
AW: Irritationen bei SetLastWriteTime/ GetLastWriteTime
Zitat:
|
AW: Irritationen bei SetLastWriteTime/ GetLastWriteTime
UTC ist eine Stunde "früher" als bei uns, da Greenwich westlich von uns liegt.
UTC entspricht der Zeit in Greenwich, unabhängig von Zeitzonen, Sommer-/Winterzeit ... Wenn es in Greenwich 9:00 Uhr ist, ist bei uns die Ortszeit 10:00 Uhr, zur Sommerzeit kommt noch eine Stunde dazu, es ist dann also um 9:00 Uhr in Greenwich bei uns 11:00 Uhr. ![]() ![]() |
AW: Irritationen bei SetLastWriteTime/ GetLastWriteTime
Da der Wikipedia-Link leider nicht richtig funktioniert:
![]() Gruß K-H |
AW: Irritationen bei SetLastWriteTime/ GetLastWriteTime
Hab' die Links nochmal bei mir ausprobiert, sie funktionieren beide.
Sollte es irgendwo, bei irgendwem Probleme geben: Wikipediaseite aufrufen und als Suchbegriff "Greenwich Mean Time" eingeben. Es gibt dort (zur Zeit) eine Fundstelle. Der zweite Suchbegriff wäre "Koordinierte Weltzeit", auch hier gibt es nur eine Ergebnisseite. Naja: Tante Google und all' ihre Schwestern liefern zu den Suchbegriffen auch noch eine Reihe Ergebnisse, die ggfls. (aus fachlicher Sicht) besser sind, als Wikipedia. |
AW: Irritationen bei SetLastWriteTime/ GetLastWriteTime
Zitat:
Set UTC - Get UTC, sollte doch die selbe Zeit bleiben, oder? Das UTC nicht unserer Ortszeit entspricht, ist mir schon kar. |
AW: Irritationen bei SetLastWriteTime/ GetLastWriteTime
Zitat:
Bei einer Datei, die ein Änderungsdatum innerhab der Sommerzeit hat, liefert dieses GetFileDateTime, genause wie auch TFile.GetLastWriteTime eine Uhrzeit, die eine Stunde früher liegt, als das vom Windows-Explorer angezeigte Änderungsdatum. |
AW: Irritationen bei SetLastWriteTime/ GetLastWriteTime
Vermutlich (steile Behauptung), weil der Windows-Explorer zur Anzeige das eigentliche Datum, also das mit GetLastWriteTime gelesene, "zeitzonen- bzw. sommerzeitkomform" umrechnet und dann das so erhaltenen Ergebnis anzeigt?
Zu prüfen wäre hier also mal, ob die von Dir genutzte Vorgehensweise die korrekt arbeitende ist und der (vermeintliche) Fehler erst durch die Anzeige durch des "Vergleichsmittel" (hier der Windows-Explorer) verursacht wird. Schau doch bitte mal auf der Kommandozeile nach, ob es dort andere Ergebnisse gibt, als mit Deiner Routine bzw. dem Windows-Explorer.
Code:
Was passiert denn, wenn Du mal (testweise) die Zeitzonen Deines Windows änderst? Bleibt das Ergebnis Deiner Routine dann unverändert, während der Windows-Explorer eine andere Zeit anzeigt?
dir
dir /TC = Erstellung dir /TA = letzter Zugriff dir /TW = letzter Schreibzugriff Habe allerdings keine Ahnung, welche anderweitigen (nicht zwingend wünschenswerten) Nebenwirkungen daraus resultieren. |
AW: Irritationen bei SetLastWriteTime/ GetLastWriteTime
Diese Vermutung hatte ich auch schon und so scheint es auch wirklich zu sein.
Der Dir-Befehl in der Eingabeaufforderung liefert die gleiche Zeit wie GetLastWriteTime, also eine Stunde früher als der Explorer. Anders allerdings die PowerShell: Hier zeigt Dir die selben Werte an wie der Explorer. Dann werde ich also weiterhin mit Set/GetLastWriteTime arbeiten und mich nicht drum kümmern, was der Explorer sagt. Bleibt allerdings noch das zweite Problem mit der UTC-Variante
Delphi-Quellcode:
Wo bleibt hier die eine Stunde? Wird da auch irgendwo etwas mit der Sommerzeit gerechnet?
TFile.SetLastWriteTimeUTC('test.txt', StrToDateTime('01.05.2020 10:00'));
TFile.GetLastWriteTimeUTC('test.txt'))); // liefert 01.05.2020 09:00 |
AW: Irritationen bei SetLastWriteTime/ GetLastWriteTime
Wiedermal nur geraten:
StrToDateTime('01.05.2020 10:00') ist die Ortszeit, entsprechend der Windowseinstellungen auf dem Rechner. Steht dort in der Zeitzone Berlin, dann ist UTC für Greenwich eine Stunde früher. Es wird für UTC also lokale Zeit minus Differenz zwischen Greenwich und Berlin genommen. Steile Behauptung: Änderst Du die Zeitzone Deines Rechners auf Tokio, so wird die Differenz 10 Stunden betragen. In Tokio ist es neun Stunden später als bei uns, bis Greenwich macht das dann -10 Stunden aus. Also sowas:
Delphi-Quellcode:
Änderst Du die Zeitzone Deines Rechners auf Seattle, wird die Differenz +8 Stunden betragen.
TFile.SetLastWriteTimeUTC('test.txt', StrToDateTime('01.05.2020 10:00'));
TFile.GetLastWriteTimeUTC('test.txt'))); // liefert 01.05.2020 00:00 Also sowas:
Delphi-Quellcode:
In Tokio ist UTC 10 Stunden weniger als die Ortszeit von Tokio, in Seattle ist UTC 8 Stunden mehr als die Ortszeit von Seattle.
TFile.SetLastWriteTimeUTC('test.txt', StrToDateTime('01.05.2020 10:00'));
TFile.GetLastWriteTimeUTC('test.txt'))); // liefert 01.05.2020 18:00 |
AW: Irritationen bei SetLastWriteTime/ GetLastWriteTime
Nein, die Datumstypen in Delphi haben keine Zeitzoneninformationen.
Das was drin steht, das steht drin, es kommt dann nur darauf an, wie man den Wert interpretiert. Ich hat mit mal den Code TFile.SetLastWriteTimeUTC und TFile.GetLastWriteTimeUTC angesehn und so weit scheint es zu stimmen, ABER dort werden zum Setzen und Lesen unterschiedliche Windows-APIs verwendet und womöglich hat Eine davon "inzwischen" eine Zeitzonenkonvertierung drin? ![]() ![]() ![]() |
AW: Irritationen bei SetLastWriteTime/ GetLastWriteTime
Hm, ohne StrToDateTime sieht es aber genauso aus:
TFile.SetLastWriteTimeUTC('test.txt', 43922.5); // entspricht 01.04.2020 12:00 TFile.GetLastWriteTimeUTC('test.txt'); // liefert 01.04.2020 11:00 Beim Umstellen der Zeitzonen bin ich auf folgendes gestoßen: Da gibt es in den Win10-Einstellungen den Schalter "Automatisch an Sommerzeit anpassen". Wenn man den ausschaltet, gibt es keine Differenz zwischen Set und Get. Das GetLastWriteTimeUTC passt die Zeit tatsächlich an die Sommerzeit an. Das hätte ich jetzt nicht vermutet. Ich dachte UTC ist die koordinierte Weltzeit, unabhängig von irgendwelchen Sommerzeitregelungen. Deshalb stellt sich jetzt die Frage: Wie komme ich an die nicht sommerzeitangepasste UTC-Dateizeit? |
AW: Irritationen bei SetLastWriteTime/ GetLastWriteTime
@himitsu
Ich bin auch nicht davon ausgegangen, dass der Zeittyp von Delphi irgendeine Zeitzoneninfo enthält. Now ist die Zeit, die gerade auf dem Rechner ist. Wenn ich die Uhr verstelle ist's halt ein anderer Wert. Das Problem, um das es hier geht, wird also bestehen bleiben. StrToDateTime macht aus 'ner Zeichenfolge ja nix weiter als einen Wert, der mehr oder weniger von Now abweicht. Die "Umwandlung", "Umrechnung", "wie auch immer" passiert also nicht innerhalb von Delphi, sondern "irgendwo auf dem Weg zwischen Delphi und dem Filesystem". Da gibt es irgendwo eine "BlackBox", die für die Differenz sorgt. Und, so wie Du vermutest, gehe ich davon aus, dass irgendwo in der Windows-API eine entsprechende Zeitzonenkonvertierung durchgeführt wird. @bcvs Das klingt für mich aber eher befremdlich. Demnach ist es, bei gesetztem Schalter "Automatisch an Sommerzeit anpassen", nicht möglich, die UTC-Zeit zu setzen. Bzw.: Man muss im Programm prüfen, ob dieser Schalter gesetzt ist und dann die Differenz zwischen Normalzeit und Sommerzeit berücksichtigen (und das bitteschön unter Beachtung aller Zeitzonen und deren ggfls. existierenden Sommerzeitregelungen) oder eben bei nicht gesetztem Schalter nicht berücksichtigen. Da mag bei einem nur lokal verwendeten Programm ja eventuell noch angehen, aber bei weltweit eingesetzter Software könnte das dann schon etwas aufwändiger werden. Das sieht mir insgesamt jetzt aber eher nach 'nem Bug als nach 'nem Feature aus (und der liegt in einem von Delphi aus nicht beeinflussbaren Bereich). Wenn ich die UTC-Zeit setze, erwarte ich eigentlich, dass diese die Zeit erhält, die ich angebe und nicht eine Zeit, die unter Beachtung diverser Schalter und wie auch immer definierter Zeitdifferenz höchstwahrscheinlich zu erwarten wäre ;-) Oder anders formuliert: Wenn ich die UTC-Zeit auf 10:00 Uhr setze, erwarte ich, dass sie beim anschließenden Lesen auch 10:00 Uhr ist. |
AW: Irritationen bei SetLastWriteTime/ GetLastWriteTime
Da ist irgendwas an deinem System anders als bei meinem (Delphi 10.3.3). Folgendes Testprogramm liefert das korrekte Ergebnis:
Delphi-Quellcode:
program Project650;
{$APPTYPE CONSOLE} uses System.IOUtils, System.SysUtils; var FileName: string; begin FileName := TPath.GetTempFileName; TFile.WriteAllText(FileName, 'Hallo Welt'); TFile.SetLastWriteTimeUTC(FileName, StrToDateTime('01.05.2020 10:00')); Writeln(DateTimeToStr(TFile.GetLastWriteTimeUTC(FileName))); Readln; end. |
AW: Irritationen bei SetLastWriteTime/ GetLastWriteTime
Ja, das wird im Dateisystemtreiber oder in der ensprechenden WinAPI gemacht. (wer genau weiß ich jetzt auch nicht, aber da wir eh nur über die APIs zugreifen, ist es egal)
Bei FAT wurde die Zeit als LocalTime gespeichert, aber NTFS speichert UTC, wobei dort im GetFileTime/SetFileTime die Zeit bereits umgerechent werd, was beim Zugriff auf FAT (z.B. Disketten oder USB-Sticks echten Spaß bereitet) @Uwe: TFile verwendet eben nicht GetFileTime Zitat:
|
AW: Irritationen bei SetLastWriteTime/ GetLastWriteTime
Zitat:
Zitat:
|
AW: Irritationen bei SetLastWriteTime/ GetLastWriteTime
Und es liegt doch an Delphi!
Uwes Testprogramm liefert mit D10.3.3 bei mir auch das korrekte Ergebnis. Mit 10.2.3 kompiliert liefert es 01.05.2020 09:00, also eine Stunde zu früh!!! Mein besagtes Projekt hatte ich noch unter 10.2.3. Wenn das die Lösung ist, kann ich aber auch problemlos auf 10.3.3. wechseln. |
AW: Irritationen bei SetLastWriteTime/ GetLastWriteTime
|
AW: Irritationen bei SetLastWriteTime/ GetLastWriteTime
Ich habe es mir jetzt nicht ganz durchgelesen, aber vielleicht hilft es:
![]() |
AW: Irritationen bei SetLastWriteTime/ GetLastWriteTime
Für derartige Fälle hab ich mir vor einiger Zeit entsprechende Hilfsfunktionen gebaut:
Delphi-Quellcode:
OK, eigentlich müsste man bei Fehlschlagen der API-Funktionen Exceptions auslösen, damit man weiß, wo's klemmt.
function FileTimeToLocalDateTime(const FileTime: TFileTime): TDateTime;
var ModifiedTime: TFileTime; SystemTime: TSystemTime; begin Result:= 0; if FileTimeToLocalFileTime(FileTime, ModifiedTime) then if FileTimeToSystemTime(ModifiedTime, SystemTime) then Result:= SystemTimeToDateTime(SystemTime); end; function UTCFileTimeToLocalDateTime(const FileTime: TFileTime): TDateTime; var UTCSystemTime, LocalSystemTime : TSystemTime; begin Result:= 0; if FileTimeToSystemTime(FileTime, UTCSystemTime) then if SystemTimeToTzSpecificLocalTime(nil, UTCSystemTime, LocalSystemTime) then Result:= SystemTimeToDateTime(LocalSystemTime); end; Grüße Dalai |
Alle Zeitangaben in WEZ +1. Es ist jetzt 22:36 Uhr. |
Powered by vBulletin® Copyright ©2000 - 2025, Jelsoft Enterprises Ltd.
LinkBacks Enabled by vBSEO © 2011, Crawlability, Inc.
Delphi-PRAXiS (c) 2002 - 2023 by Daniel R. Wolf, 2024 by Thomas Breitkreuz