Irritationen bei SetLastWriteTime/ GetLastWriteTime

[bcvs]

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.
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:

TFile.SetLastWriteTimeUTC('test.txt', StrToDateTime('01.05.2020 10:00'));
ShowMessage(DateTimeToStr(TFile.GetLastWriteTimeUTC('test.txt'))); // zeigt 01.05.2020 09:00

Wieso 09:00, wo ist die Stunde geblieben? Sollte da nicht nach Set... und Get.. wieder das selbe rauskommen?
Passiert auch nur bei Daten innerhalb der Sommerzeit.

[DieDolly]

Zitat:

TFile.GetLastWriteTimeUTC('test.txt')

Weil es die UTC-Zeit zurückgibt. Steht doch da. Oder irre ich mich?

[Delphi.Narium]

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.

Greenwich Mean Time = GMT entspricht (fast) UTC = Coordinated Universal Time

[p80286]

Da der Wikipedia-Link leider nicht richtig funktioniert:https://www.timeanddate.com/time/aboututc.html

Gruß
K-H

[Delphi.Narium]

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.

[bcvs]

Zitat von DieDolly:

Zitat:

TFile.GetLastWriteTimeUTC('test.txt')

Weil es die UTC-Zeit zurückgibt. Steht doch da. Oder irre ich mich?

Ja, aber eine Zeile darüber habe auch die UTC-Zeit geschrieben.
Set UTC - Get UTC, sollte doch die selbe Zeit bleiben, oder?

Das UTC nicht unserer Ortszeit entspricht, ist mir schon kar.

[bcvs]

Zitat von Frühlingsrolle:

Damit sollte die 'lokale' Zeitangabe der Datei erhoben werden können:

Danke, aber damit sind wir bei dem ersten Problem aus meinem Ursprungspost.

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.

[Delphi.Narium]

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:

dir
dir /TC = Erstellung
dir /TA = letzter Zugriff
dir /TW = letzter Schreibzugriff

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?
Habe allerdings keine Ahnung, welche anderweitigen (nicht zwingend wünschenswerten) Nebenwirkungen daraus resultieren.

[bcvs]

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:

TFile.SetLastWriteTimeUTC('test.txt', StrToDateTime('01.05.2020 10:00'));
TFile.GetLastWriteTimeUTC('test.txt'))); // liefert 01.05.2020 09:00

Wo bleibt hier die eine Stunde? Wird da auch irgendwo etwas mit der Sommerzeit gerechnet?

[Delphi.Narium]

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:

TFile.SetLastWriteTimeUTC('test.txt', StrToDateTime('01.05.2020 10:00'));
TFile.GetLastWriteTimeUTC('test.txt'))); // liefert 01.05.2020 00:00

Änderst Du die Zeitzone Deines Rechners auf Seattle, wird die Differenz +8 Stunden betragen.
Also sowas:

Delphi-Quellcode:

TFile.SetLastWriteTimeUTC('test.txt', StrToDateTime('01.05.2020 10:00'));
TFile.GetLastWriteTimeUTC('test.txt'))); // liefert 01.05.2020 18:00

In Tokio ist UTC 10 Stunden weniger als die Ortszeit von Tokio, in Seattle ist UTC 8 Stunden mehr als die Ortszeit von Seattle.