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