DateTime to uint32_t

[Zo R. (hsch1978)]

Hallo,

ich habe folgendes Problem mit einer Konvertierung.
In einer DateTime Struktur ist der Tag, Monat und Jahr enthalten.
Der Tag und Monat ist vom Datentyp uin8_t. Das Jahr hat den Datentyp 
uint16_t.
Jetzt sollen alle drei Werte in eine uin32_t Datentyp kopiert werden.

Beispiel:
Tag (uint8_t) = 5
Monat(uint8_t = 7
Jahr(uint16_t) = 23

Im folgenden soll dann die drei Werte so in der Variable drin stehen:
datetime_variable(uint32_t) = 5072023

[Klaus (feelfree)]

datetime = Tag * 1000000 + Monat * 10000 + Jahr

War jetzt ncht soo schwierig, oder?

[Stefan F. (Gast)]

datetime_variable = Tag*100000UL + Monat*10000UL + Jahr+2000

Ist das eine Hausaufgabe oder steckt da ein tieferer Sinn hinter? Ich 
frage, weil ein Zeitpunkt als unit32 normalerweise völlig anders 
aussieht, nämlich Sekunden nach dem 1.1.1970 00:00:00.

[Klaus (feelfree)]

Stefan F. schrieb:
> +2000

Upps, da hat Du recht. Warum aber das Jahr in einem uint16_t steckt wenn 
es nur 2-stellig abgespeichert wird...?

[Zo R. (hsch1978)]

Vielen Dank!

EInen Punkt hätte ich noch. Der Monat soll nicht eine Stelle haben zum 
Beispiel beim Monat 4 sondern soll 04 anzeigen:

3042023

[Stefan F. (Gast)]

Stefan F. schrieb:
> datetime_variable = Tag*100000UL + Monat*10000UL + Jahr+2000

Da fehlt eine Null
> datetime_variable = Tag*1000000UL + Monat*10000UL + Jahr+2000

[Stefan F. (Gast)]

He S. schrieb:
> EInen Punkt hätte ich noch. Der Monat soll nicht eine Stelle haben zum
> Beispiel beim Monat 4 sondern soll 04 anzeigen:

Das ergibt sich von ganz alleine, weil der Tag davor steht.

[Zo R. (hsch1978)]

Ich danke euch

[Rainer W. (rawi)]

He S. schrieb:
> Im folgenden soll dann die drei Werte so in der Variable drin stehen:
> datetime_variable(uint32_t) = 5072023

Die Reihenfolge ist schon ein bisschen abartig.
Welchen tiefen Sinn mag es haben, die Wertigkeit der Stellen derart 
durcheinander zu würfeln?
Jeder Größer-/Kleiner-Vergleich (Sortieren) wird damit zu einer 
mittleren Orgie.

Stefan F. schrieb:
> Ich frage, weil ein Zeitpunkt als unit32 normalerweise völlig
> anders aussieht, nämlich Sekunden nach dem 1.1.1970 00:00:00.

Das wird schon spaßig, wenn man den 31.12.1969 23:59:59 in der Kodierung 
darstellen möchte.

[Marc V. (Firma: Vescomp) (logarithmus)]

He S. schrieb:
> Vielen Dank!
>
> EInen Punkt hätte ich noch. Der Monat soll nicht eine Stelle haben zum
> Beispiel beim Monat 4 sondern soll 04 anzeigen:
>
> 3042023

Normalerweise steht das Jahr zuerst.
Warum?
Damit sortieren leichter wird, das ist wohl auch der Sinn
des Ganzen.

[Joe L. (joelisa)]

Rainer W. schrieb:
> He S. schrieb:
>> Im folgenden soll dann die drei Werte so in der Variable drin stehen:
>> datetime_variable(uint32_t) = 5072023
>
> Die Reihenfolge ist schon ein bisschen abartig.
> Welchen tiefen Sinn mag es haben, die Wertigkeit der Stellen derart
> durcheinander zu würfeln?
> Jeder Größer-/Kleiner-Vergleich (Sortieren) wird damit zu einer
> mittleren Orgie.

Agree!

Würden sich die Leute blos mal die ISO-8601 (oder auch DIN-5008, rfc3339 
...) ansehen, als immer was Neues "erfinden" zu wollen ...

> Stefan F. schrieb:
>> Ich frage, weil ein Zeitpunkt als unit32 normalerweise völlig
>> anders aussieht, nämlich Sekunden nach dem 1.1.1970 00:00:00.
>
> Das wird schon spaßig, wenn man den 31.12.1969 23:59:59 in der Kodierung
> darstellen möchte.

Jede Codierung hat seine Schwächen - besonders aber die des TO's, 
angefangen bei seinem "Jahr(uint16_t)". Vor dem Jahr 2000 ist da nichts 
...

Stefan F.'s Vorschlag ist etwas unvollständig dargestellt. Die Unix 
Epoch auf die er sich wohl bezieht (Unix time  POSIX time  Unix 
timestamp), "ist die Anzahl der Sekunden, die seit dem 1. Januar 1970 
(Mitternacht UTC/GMT) vergangen sind, ohne Schaltsekunden (in 
ISO-8601-Darstellung also 1970-01-01T00:00:00Z)".

Siehe auch: https://de.wikipedia.org/wiki/Unixzeit. Dort wird auch auf 
das Jahr-2038-Problem (eine weiter Schwäche) eingegangen.

Eine umfassende Zusammenstellung findet sich z.B. unter 
https://www.epochconverter.com/

[Alexander (alecxs)]

He S. schrieb:
> 3042023

30.04.2023? jede Kamera macht das seit Jahrzenten richtig 
IMG_20230508_120522.jpg

[Rainer W. (rawi)]

Joe L. schrieb:
> Würden sich die Leute blos mal die ISO-8601 (oder auch DIN-5008, rfc3339
> ...) ansehen, als immer was Neues "erfinden" zu wollen ...

Selbst die DIN-5008 hat wegen der Dickköpfigkeit deutscher Schreibstuben 
nach fünf Jahren den Rückzug angetreten und seit der Ausgabe 2001, neben 
der Form 'YYYY-MM-DD' nach ISO-8601, das Format 'TT.MM.JJJJ' als wieder 
zulässig erklärt. Immerhin ist die Nutzung dieses Formates seit 2020 auf 
inländischen Schriftverkehr beschränkt worden.

[Horst S. (h3aau)]

union Datum {
int_8 Tag;
int_8 Monat;
int_16 Jahr;
};

schon mal darüber nachgedacht?

[Klaus (feelfree)]

Horst S. schrieb:
> schon mal darüber nachgedacht?

Ja, und als untauglicher Ansatz für das beschriebene Problem verworfen.

[Joe L. (joelisa)]

Rainer W. schrieb:
> Selbst die DIN-5008 hat wegen der Dickköpfigkeit deutscher Schreibstuben
> nach fünf Jahren den Rückzug angetreten und seit der Ausgabe 2001, neben
> der Form 'YYYY-MM-DD' nach ISO-8601, das Format 'TT.MM.JJJJ' als wieder
> zulässig erklärt.

Fürwahr sitzen in denselben Schreibstuben -- und nicht nur da ! -- 
weiterhin die gleichen talentfreien Schnellmerker, die sich aktuell der 
Hoffnung ergeben, die staatlich verordnete Digitalisierung möge sich 
positiv auf ihren Intellekt auswirken.

Bei allem gebührenden Respekt erlaube ich mir schon jetzt zu orakeln, 
dass dem nicht so sein wird! Aber auch ich irre mich zuweilen ...

[Joe L. (joelisa)]

Horst S. schrieb:
> union Datum {
> int_8 Tag;
> int_8 Monat;
> int_16 Jahr;
> };

GENIAL! Horst - you made my day!