3. long timestamp to SYSTEMTIME

long timestamp to SYSTEMTIME

  • P

    * Convert the SYSTEMTIME structure to a FILETIME structure.
    * Copy the resulting FILETIME structure to a ULARGE_INTEGER structure.
    * Use normal 64-bit arithmetic on the ULARGE_INTEGER value.

    Das wusste ich schon vor 2 Tagen.......

    0
  • B

    Und warum machst du es dann nicht so?

    // Deine Daten
SYSTEMTIME sys_time;
ULARGE_INTEGER time_to_subtract;

union
{
    FILETIME ft;
    ULARGE_INTEGER ts;
} t;

SystemTimeToFileTime( &sys_time, &t.ft );
t.ts -= time_to_subtract;
FileTimeToSystemTime( &t.ft, &sys_time );
    0
  • P

    Da gibts nur einen Grund. Ich bin da nicht drauf gekommen und wär ich wohl auch nicht.

    Vielen Dank, werds gleich probieren! 🙂

    PS: Und warum gibts im MSDN bei jedem Beispiel mind. 100 Zeilen Code? Das habe ich mich schon immer gefragt.

    0
  • B

    plizer schrieb:

    PS: Und warum gibts im MSDN bei jedem Beispiel mind. 100 Zeilen Code? Das habe ich mich schon immer gefragt.

    Damit man's besser versteht 😃

    Übrigens hab ich für den Code jetzt nur 12 Sekunden und keine 2 Tage gebraucht 🙂 Also doch besser als Java 🤡

    PS: Und es geht mir genauso, wenn ich mal Java oder C# programmieren muss. Ich glaub das ist bei jedem Umstieg so 😉

    0
  • L

    Badestrand schrieb:

    PS: Und es geht mir genauso, wenn ich mal Java oder C# programmieren muss. Ich glaub das ist bei jedem Umstieg so 😉

    Sehe ich genauso. Ich habe neulich graue Haare bekommen als ich in Java mit Timestamps, Timespans und Calendars rumhantieren musste...

    0
  • S

    Hi,

    auch als glühender C++-Verehrer muss ich aber zugeben, dass das Thema "Zeit/Datum" schon seeeehr schwach spezifiziert ist.
    Da sollte beim nächsten Standard mal dringend nachgearbeitet werden.

    Gruß,

    Simon2.

    0
  • B

    Hat jemand schon mal boost::date_time verwendet? Wie sind da die Erfahrungen?

    0
  • P

    Wird in dem Beispiel überhaupt die systemtime verändert?

    SystemTimeToFileTime( &sys_time, &t.ft );
t.ts -= time_to_subtract;
FileTimeToSystemTime( &t.ft, &sys_time );

    Das ts wird zwar verändert, allerdings hat es doch nie was mit systemtime zu tun?!?

    0
  • B

    ts wird ja wieder nach SYSTEM_TIME konvertiert (das Ergebnis wird in sys_time gespeichert), in der dritten von dir zitierten Zeile 🙂

    0
  • P

    Badestrand schrieb:

    ts wird ja wieder nach SYSTEM_TIME konvertiert (das Ergebnis wird in sys_time gespeichert), in der dritten von dir zitierten Zeile 🙂

    Also, so sieht das aus:

    // Deine Daten
SYSTEMTIME sys_time; // z.B. 2007-10-10 10:00:00
ULARGE_INTEGER time_to_subtract; // z.B. 600, sind dann doch 600 Sekunden?

union
{
    FILETIME ft;
    ULARGE_INTEGER ts;
} t;

SystemTimeToFileTime( &sys_time, &t.ft ); // hier wird in ft genau das hier übernommen:  2007-10-10 10:00:00, natürlich ganz anders gespeichert, weil FILETIME ja anders arbeitet.

t.ts -= time_to_subtract; // Das Attribut von der union t (ich hab noch nie union vorher gesehen) ts wird um 600 verringert.
FileTimeToSystemTime( &t.ft, &sys_time ); // Wieso ist denn in t.ft jetzt das um 600 reduzierte Ergebnis drin?!?
    0
  • B

    Alle Elemente einer Union teilen sich den gleichen Speichplatz. Wenn als jetzt ts um 600 verringert wird ist ft automatisch auch um 600 verringert.

    0
  • P

    Braunstein schrieb:

    Alle Elemente einer Union teilen sich den gleichen Speichplatz. Wenn als jetzt ts um 600 verringert wird ist ft automatisch auch um 600 verringert.

    Aso! Alles klar. Das hatte ich noch gewusst, aber wusste nicht, dass das in der Praxis dann genau so aussieht! Danke!

    0
  • P

    Welche Zahlentyp ist eigentlich kompatibel zu ULARGE_INTEGER? (und warum gibt es so einen Datentypen überhaupt, wenn es schon zig andere gibt?)

    Ich habe es mit:

    int
long
unsigned int 
unsigned long

    versucht. Aber da meckert überall der Compiler... 😞
    Jemand nen Tipp?

    0
  • L

    plizer schrieb:

    (und warum gibt es so einen Datentypen überhaupt, wenn es schon zig andere gibt?)

    Weil es im Standard keinen echten 64-bit Datentyp gibt z.B.? 😉

    Der MS-Compiler müsste mit unsigned long long klarkommen. Aber ULARGE_INTEGER könnte imho auch eine Struktur mit zwei unsigned int Feldern sein, dann lassen sie sich zumindest nicht direkt zuweisen.

    0
  • B

    Es ist eine Union die beides enthält. unsigned long long und eine struct mit zwei int.

    0
  • P

    Ok, das könnt ein Grund sein ;-).

    Bei unsigned long long meckert der Compiler. Das ULARGE_INTEGER ist eine union. Dachte auch die könnte man zuweisen. Muss mal schauen wie das dann anders geht...

    0
  • P

    @Braunstein: Danke. Ich habe einen int-Wert und den will ich dem ULARGE_INTEGER zuweisen. Was muss ich da denn dann genau machen (ich glaube ich werde C++ nie verstehen)?

    0
  • C

    Entweder direkt an li.QuadPart zuweisen oder an li.u.LowPart (im letzteren Fall mußt du HighPart auf Null setzen):

    int i = 4711;
ULARGE_INTEGER li;

//a:
li.QuadPart = i;

//b:
li.u.LowPart = i;//oder li.LowPart=i
li.u.HighPart = 0;//oder li.HighPart=0
    0
  • P

    Meine Methode sieht jetzt so aus:

    SYSTEMTIME CMainDlg :: systemtimeReduzieren(SYSTEMTIME datetime, int reduzierungAnzahlVonSekunden) {
	// Deine Daten
	SYSTEMTIME sys_time;
	ULARGE_INTEGER time_to_subtract;
	time_to_subtract.QuadPart = reduzierungAnzahlVonSekunden;

	union
	{
		FILETIME ft;
		ULARGE_INTEGER ts;
	} t;

	SystemTimeToFileTime( &datetime, &t.ft );
	t.ts -= time_to_subtract;
	FileTimeToSystemTime( &t.ft, &sys_time );

	return sys_time;
}

    Dann meckert allerdings der Compiler folgendermaßen:

    error C2676: Binaerer Operator '-=' : 'union _ULARGE_INTEGER' definiert diesen Operator oder eine Konvertierung in einen für den vordefinierten Operator geeigneten Typ nicht

    0
  • B

    Du könntest es so machen

    t.ts.QuadPart -= time_to_subtract;
    0
Anmelden zum Antworten