Time format von c++ nach c#

[booster]

@hustbaer sagte in Time format von c++ nach c#:

https://en.cppreference.com/w/c/chrono/localtime behauptet dass localtime_s ein C11 Feature wäre. Ich hätte es mit Godbolt probiert, scheint kein aktuelles System zu haben.

jo so steht es da, ein c11 feature. Und wie komme ich an das c11 feature ran und nicht an die MSVC Erweiterung?
Was ist godbolt und wer oder was "scheint kein aktuelles System zu haben"

struct tm buf;
auto time = std::chrono::system_clock::to_time_t(std::chrono::system_clock::now() - std::chrono::hours(24));
localtime_s(&buf, &time);
stringstream ss;
ss << std::put_time(&buf, "%F %T");
auto timestamp = ss.str();

ganz einfach in einem 6 Zeiler was in c# mit einem 1 Zeiler geht.

Dieses Format lässt sich dann aber zum Glück dann in ein Datetime in c# wandeln. Geht doch! Wieso einfach wenn es auch kompliziert geht.

Also manchmal ist das ganze ja schon ziemlich suspekt.

1. Beispiele passen nicht, sind veraltet.
2. Wieso muss man das Zeitformat überhaupt erst 5 mal umwandeln.
3. Wieso ist das so kompliziert dass einem auch noch dazu geraten wird eine lib von github runter zu laden
4. Und dann auch noch solche pragmatischen Lösungen wie einfach _CRT_SECURE_NO_WARNINGS definieren.
   Damit es beim nächsten Compiler Update auf jeden Fall kracht.

[wob]

@booster sagte in Time format von c++ nach c#:

Was ist godbolt

Matt Godbolt. Jemand, der einen "Compiler Explorer" entwickelt hat. Großartiges Tool -> https://gcc.godbolt.org

Also manchmal ist das ganze ja schon ziemlich suspekt.

1. Beispiele passen nicht, sind veraltet.

Tja.

2. Wieso muss man das Zeitformat überhaupt erst 5 mal umwandeln.

Solltest du besser nicht, da du so Präzision verlierst, da time_t in Sekunden ist. Deine system_clock hat aber vermutlich eine höhere Präzision.

3. Wieso ist das so kompliziert dass einem auch noch dazu geraten wird eine lib von github runter zu laden

Diese lib wird (so ähnlich) in C++20 vorhanden sein. Sozusagen "from future import date", wenn es Python wäre.
Es ist so kompliziert, weil die C++-Zeittypen unglaublich viele Dinge unterstützen. Wie zum Beispiel verschiedene Uhren, zum Beispiel die GPS-Uhr. Es gibt Schaltsekunden, Schalttage, sich ändernde Zeitzonen, ... Datumsberechnung ist nicht einfach. Du kannst verschiedene Datentypen für die Uhr bzw. die Länge wählen. Das alles typsicher. Dennoch ein Punkt für dich: ohne das date.h sind gewissen Dinge nervig zu implementieren.

[hustbaer]

@booster sagte in Time format von c++ nach c#:

jo so steht es da, ein c11 feature. Und wie komme ich an das c11 feature ran und nicht an die MSVC Erweiterung?

Na vermutlich gar nicht wenn du C++ verwendest. Und vermutlich nichtmal wenn du C verwendest. Weil halt

scheint kein aktuelles System zu haben.

was "scheint kein aktuelles System zu haben"

Na die optionale (!) Erweiterung die localtime_s enthält.

[Ein ehemaliger Benutzer]

@booster sagte in Time format von c++ nach c#:

4. Und dann auch noch solche pragmatischen Lösungen wie einfach _CRT_SECURE_NO_WARNINGS definieren.
   Damit es beim nächsten Compiler Update auf jeden Fall kracht.

naja eigentlich sorgt diese anweisung nur dafür, dass "gefährliche" funktionen der c-standardbibliothek (gets, scanf, localtime usw) nicht durch microsoft-spezifische funktionen mit _s hinten dran ersetzt werden müssen.

aber warum bietet c# eigentlich keine möglichkeit, den unixzeitstempel in lokalzeit umzuwandeln?

[firefly]

@Wade1234 sagte in Time format von c++ nach c#:

aber warum bietet c# eigentlich keine möglichkeit, den unixzeitstempel in lokalzeit umzuwandeln?

Ich beantworte mal deine Frage: https://docs.microsoft.com/de-de/dotnet/api/system.datetimeoffset.fromunixtimeseconds?view=netframework-4.7.2

[Ein ehemaliger Benutzer]

und warum wird das dann nicht verwendet?

[booster]

@Wade1234 sagte in Time format von c++ nach c#:

und warum wird das dann nicht verwendet?

Die Präzision spielt eigentlich keine so große Rolle. Schaden tut sie allerdings auch nicht. Vorteil die Zeit war leserlich in der json Struktur. Aber auch nicht entscheidend.

also mit

auto now = std::chrono::system_clock::now();

erhalte ich einen time_point. Den wandle ich dann mit

now.time_since_epoch().count();

in einen int ?? Den kann ich dann an c# übertragen. Richtig?

[Swordfish]

@booster hast du es versucht? wenn ja: funktionierts? wenn nein: was ist falsch?

[booster]

@Swordfish

ja habe es versucht.
ja es funktioniert.
mir war nur nicht klar ob das dann die richtige vorgehensweise ist.
Aber danke.

[Ein ehemaliger Benutzer]

es gibt doch system_clock::to_time_t, was, wenn ich das jetzt nicht falsch sehe, den unixzeitstempel ergibt. den kannst du dann an c# übertragen und da umwandeln. ganz ohne aufwand und ohne #define _CRT_SECURE_NO_WARNINGS.

[booster]

@Wade1234 sagte in Time format von c++ nach c#:

es gibt doch system_clock::to_time_t, was, wenn ich das jetzt nicht falsch sehe, den unixzeitstempel ergibt

ja, und was macht time_since_epoch()?

[Ein ehemaliger Benutzer]

wenn ich das richtig sehe, mikrosekunden dran hängen. keine ahnung, dein problem ist ja gelöst.

[booster]

Problem ist gelöst. Das mit dem to_time_t hatte ich mir auch angeschaut. Aber nicht ganz verstanden was der unterschied ist zu time_since_epoch().

Darum habe ich gefragt ob meine Lösung die richtige ist. Man will ja nicht nur das Problem lösen sondern auch was dazu lernen.

[firefly]

Die Genauigkeit von time_t ist implementierungsspezifisch.
https://en.cppreference.com/w/cpp/chrono/system_clock/to_time_t

[Ein ehemaliger Benutzer]

naja time_t ist immer eine ganze anzahl von sekunden seit dem 1.1.1970, das ist für uhrzeiten eigentlich genau genug.

also ich würde dann eher sagen, dass to_time_t das richtige ist, weil das ja auch das ist, was fromunixtimeseconds unter c# dann erwartet. aber warum funktioniert time_since_epoch dann?

[wob]

@booster sagte in Time format von c++ nach c#:

ja, und was macht time_since_epoch()?

Das gibt die Anzahl der "Ticks" seit der epoch an.
Wobei die "Ticks" nicht unbedingt Sekunden sind. Das hängt von deiner time_point-Genauigkeit ab.

Beispiel:

auto n = chrono::system_clock::now()
(std::chrono::time_point<std::chrono::system_clock, std::chrono::duration<long, std::ratio<1, 1000000000> > > &) @0x7f714c619010
n.time_since_epoch().count()
(long) 1550837538050613745
// In der Einheit std::ratio<1, 1000000000>, also 1 ns

auto h = std::chrono::time_point_cast<std::chrono::hours>(n)
(std::chrono::time_point<std::chrono::system_clock, std::chrono::duration<long, std::ratio<3600, 1> > > &) @0x7f714c619018
h.time_since_epoch().count()
(long) 430788
// in der Einheit std::ratio<3600, 1>, also 3600 Sekunden, also 1 Stunde

time_since_epoch().count() ist also nur dann in Sekunden (seit 1970*), wenn du als Duration-Einheit die Sekunde hast.

* nur per Konvention, nicht vom Standard garantiert