TimeDateStamp im IMAGE_FILE_HEADER unterschiedlich

[Dalai]

Hallo Leute ,

beim erneuten Kompilieren eines Projekts mit XE2 ist mir eine seltsame Sache aufgefallen. Ausgangspunkt ist ein Kompilat desselben Projekts, einmal vom 01. März und einmal von heute. Beide Dateien liegen auf einem NTFS-Dateisystem.

Das Kompilat vom 01. März:

• hat diesen TimeDateStamp im Header: Sun Mar 01 17:45:16 2015 (UTC)
• die Datei hat den Zeitstempel Sun Mar 01 18:45:16 2015 (lokale Zeit, GMT+1)

Das Kompilat von heute (14. März):

• hat diesen TimeDateStamp im Header: Sat Mar 14 17:00:56 2015 (UTC)
• die Datei hat den Zeitstempel Sat Mar 14 19:00:56 2015 (lokale Zeit, GMT+1)

Die Abweichung zwischen UTC und lokaler Zeit war am 01. März also eine Stunde, heute sind es zwei . Laut Microsoft gibt der TimeDateStamp im IMAGE_FILE_HEADER die Zeit in UTC seit Epoch (01.01.1970 00:00) an. UTC ist nach meinem Wissen konstant, d.h. unbeeinflusst von irgendwelchen lokalen Zeiten oder DST (Sommerzeit). An GMT+1 hat sich während der letzten 14 Tage auch nichts verändert.

Hab ich was verpasst oder woher kommt die eine Stunde mehr?

[EDIT]
Die Angaben des TimeDateStamp hab ich einerseits mit einer eigenen Funktion und andererseits mit dem Tool PE TimeDateStamp Viewer ermittelt.
[/EDIT]

MfG Dalai

[hathor]

Du bist auf die doofen Amerikaner hereingefallen:
California daylight savings time
Start DST: Sonntag, 8. März 2015, 1 hour forward.

Wahrscheinlich hast Du FALSCHE automatische Updates bekommen.

Auf Deutschland bezogen wäre das dann UTC/GMT +2 hours.
http://www.timeanddate.com/time/zone/germany/berlin

[Dalai]

Zitat von hathor:

Du bist auf die doofen Amerikaner hereingefallen:
California daylight savings time
Start DST: Sonntag, 8. März 2015, 1 hour forward.

Inwiefern spielt diese Zeitzone auf meinem deutschen Windows mit GMT+1 eine Rolle? Das betrifft übrigens alle Systeme, darunter auch ein Win2k.

Zitat:

Wahrscheinlich hast Du FALSCHE automatische Updates bekommen.

Meine Systeme bekommen keine Updates mehr (weil XP), und bei den besonders wichtigen Programmier-VMs spiele ich erst recht keine ein - wozu sollte ich, wenn jedes Update ein Risiko oder in letzter Zeit sogar ein Glücksspiel ist? Die Kisten hängen zwar normal im LAN, aber Internet wird dort eh nicht genutzt, also gibt's auch kein Einfallstor.

MfG Dalai

[hathor]

WOHER kommt dann die SYSTEMZEIT?
Gibt es einen TIMESERVER im Netzwerk?

Wenn ich eine Funktion mit falschen Daten füttere (z.B. LocalDateTimeFromUTCDateTime(now) ), dann kommen natürlich falsche Daten heraus.

[Dalai]

Zitat von hathor:

WOHER kommt dann die SYSTEMZEIT?

Vom OS natürlich.

Zitat:

Gibt es einen TIMESERVER im Netzwerk?

Selbstverständlich. Aber nur die echten Systeme holen sich einmal täglich die Zeit von diesem (mit AboutTime), die VMs nicht. Es betrifft aber alle Systeme.

Zitat:

Wenn ich eine Funktion mit falschen Daten füttere (z.B. LocalDateTimeFromUTCDateTime(now) ), dann kommen natürlich falsche Daten heraus.

Ich berechne in meinem Code keine lokale Zeit (ebensowenig wie das angesprochene Tool, schätze ich mal). Ich hole mir mit dieser Funktion den TimeDateStamp aus dem Executable:

Delphi-Quellcode:

{$IFDEF DELPHI2009_AND_UP}

{ The following two functions are (C) TOndrej @ StackOverflow
  http://stackoverflow.com/questions/8437300/how-can-i-automate-getting-the-date-of-build-into-a-constant-visible-to-my-code }

function LinkerTimeStamp(const FileName: AnsiString): TDateTime;
var
  LI: TLoadedImage;
begin
  if NOT MapAndLoad(PAnsiChar(FileName), nil, @LI, False, True) then
      RaiseLastOsError;
  Result := LI.FileHeader.FileHeader.TimeDateStamp / SecsPerDay + UnixDateDelta;
  UnMapAndLoad(@LI);
end;

//------------------------------------------------------------------------------

function LinkerTimestamp: TDateTime;
begin
    Result := PImageNtHeaders(HInstance
                              + PImageDosHeader(HInstance)^._lfanew)^.FileHeader.TimeDateStamp
                              / SecsPerDay
                              + UnixDateDelta;
end;
{$ENDIF}

Und vergleiche dessen Ausgabe mit dem Zeitstempel des Executable selbst, den man im Total Commander, Explorer oder woanders ablesen kann. Probier mal die Funktion selbst aus, vermutlich bekommst du dann auch zwei Stunden Abweichung, obwohl es laut Zeitzone GMT+1 nur eine sein dürfte.

MfG Dalai

[hathor]

Kleines Testprogramm:
Anzeige in Deutschland:
Current universal time is: 15.03.2015 13:38:25
15.03.2015 14:38:25 (GMT+01)
Current time is Standard.

Was zeigt es bei Dir an?

Delphi-Quellcode:

program dates;

{$APPTYPE CONSOLE}
uses
  SysUtils, DateUtils;

begin
  { Writes the current universal time }
  WriteLn('Current universal time is: ',
  DateTimeToStr(TTimeZone.Local.ToUniversalTime(Now)));

  { Write the current date/time along with the abbreviation }
  WriteLn(
    Format('%s (%s)', [DateTimeToStr(Now),
      TTimeZone.Local.GetAbbreviation(Now, true)]));

  { Simply write the type of the current time }
  case TTimeZone.Local.GetLocalTimeType(Now) of
    lttStandard: WriteLn('Current time is Standard.');

    lttDaylight: WriteLn('Current time is Daylight.');

    lttInvalid:  WriteLn('This should never happen when the time is coming from the system.');

    lttAmbiguous:WriteLn('Current time is ambiguous.');
  end;
  Readln;
end.

[Dalai]

Zitat von hathor:

Kleines Testprogramm:
Anzeige in Deutschland:
Current universal time is: 15.03.2015 13:38:25
15.03.2015 14:38:25 (GMT+01)
Current time is Standard.

Was zeigt es bei Dir an?

Code:

Current universal time is: 15.03.2015 13:42:01
15.03.2015 14:42:01 (GMT+01)
Current time is Standard.

MfG Dalai

[hathor]

Ich gebe es auf!
Ich denke, dass EMBA da Mist gebaut hat, denn bei älteren Compilaten ist der Timestamp = GMT, bei neueren Compilaten ist der Timestamp = GMT -1, was eine Differenz von 2 Stunden zu unserer Normalzeit = Standardzeit = Winterzeit GMT +1 bewirkt.

[himitsu]

Es wurde auch umgebaut.

Früher stand die Zeit nicht im Image-Header, an der Stelle, wo es hingehört, sondern dort stand nur eine Magig-Number und der Wert stand wo anders.
Jetzt steht es richtig drin (zumindestens die Stelle)

[Dalai]

@himitsu: Das ist mir klar, dass z.B. Delphi 5 noch einen konstanten Wert 20.06.1992 22:22 UTC als TimeDateStamp eingetragen hat. Aber darum geht es ja nicht, da die fraglichen Kompilate mit XE2 erzeugt wurden (wie bereits im OP erwähnt).

MfG Dalai