FreeRTOS tm structure verwirrende Dokumentation

[Johannes (Gast)]

Einen schönen guten morgen.
Ich habe eine frage zu FreeRTOS.
https://www.freertos.org/API/FreeRTOS_POSIX_time.html
und zwar geht es um die Struktur tm (Zeit)

Sind das Kopierfehler?
tm_hour -> Minutes
tm_mday -> Seconds
tm_mon -> Seconds

Warum fangen alle bei 0 an außer Tag? Dieser fängt bei 1 an.
Warum gehen tm_sec von [0,60]?
Genauso tm_yday [0,365]

[Johannes (Gast)]

Ahso,
meine Folgende Ausgabe ist momentan wie folg

timeSyncCb: unixtime: 1616314743
time: timings: day: 21    month: 2    year: 121    wday: 0    yday: 79

es passt alles (day fängt bei 1 an, month bei 0 und year muss noch 1900 
addiert werden)
Aber das ist alles ein bisschen verwirrend, da man die unterschiedlichen 
struct-members unterschiedlich auswerten muss.

Das ergebneis habe ich mit

localtime_r(&unixTime, &utcTime);

wobei unixTime 1616314743 ist.

[PittyJ (Gast)]

Das wird ähnlich zu C und Unix sein, wo es seit Jahrzehntenn die struct 
tm gibt, die ähnlich aufgebaut ist.

https://www.cplusplus.com/reference/ctime/tm/

Davon sollte man schon mal gehört haben ...

[Johannes (Gast)]

PittyJ schrieb:
> Das wird ähnlich zu C und Unix sein, wo es seit Jahrzehntenn die struct
> tm gibt, die ähnlich aufgebaut ist.
>
> https://www.cplusplus.com/reference/ctime/tm/

ok, das mit den Sekunden ist klar und macht sinn. die Schaltsekunde 
hatte ich nicht berücksichtigt.

Die Kommentare zu tm_hour, tm_mday, tm_mon setze ich jetzt mal als 
kopierfeheler an (obwohl das alles schon so alt ist, wurde es noch nie 
korrigiert? naja).

Aber warum tm_day bei 1 an und alle anderen bei 0?

[g457 (Gast)]

> Aber warum tm_day bei 1 an und alle anderen bei 0?

..weil im realen Kalender die Tage bei 1 anfangen und die anderen Werte 
jeweils bei 0..??

[Johannes (Gast)]

g457 schrieb:
> ..weil im realen Kalender die Tage bei 1 anfangen und die anderen Werte
> jeweils bei 0..??

Bei den Zeiten (sekunden, minuten, studen) gebe ich dir recht.
Aber bei mir fängt der Januar mit 1 an.

Es steht zwar dort month 'since' january, wodurch die 0 wieder sinn 
ergibt, aber warum dann nicht day 'since' first

[A. S. (Gast)]

Johannes schrieb:
> aber warum dann nicht day 'since' first

anders herum: Wozu?

Der 5.Februar kann zwar als 5.2. ausgeschrieben werden, aber für die 5 
gibt es kein äquivalent, dass mit 4 irgendwie Sinn macht.

Die 1 für Februar ist i.d.R. der C-übliche zweite Eintrag in einer Liste 
von ausgeschriebenen oder abgekürzten Monatsnamen. Warum sollte man da 
mit einem leeren Element anfangen.

Beim Tag existiert keine solche Liste.

[Johannes (Gast)]

A. S. schrieb:
> Die 1 für Februar ist i.d.R. der C-übliche zweite Eintrag in einer Liste
> von ausgeschriebenen oder abgekürzten Monatsnamen. Warum sollte man da
> mit einem leeren Element anfangen.
>
> Beim Tag existiert keine solche Liste.

Ja, auch das ist sinnig.
Da habe ich auch nicht dran gedacht.

Also wenn man an alles denkt, ergibt auch alles sinn.

Auf den ersten blick war es für mich dennoch ein bisschen verwirrend ;)

[Rolf M. (rmagnus)]

A. S. schrieb:
> Johannes schrieb:
>> aber warum dann nicht day 'since' first
>
> anders herum: Wozu?

Weil im üblichen Gebrauch von Datum sowohl Tag, als auch Monat mit der 1 
anfangen. Da ist es etwas unintuitiv, hier zwar beim Tag, nicht aber 
beim Monat mit der 1 anzufangen.

A. S. schrieb:
> Die 1 für Februar ist i.d.R. der C-übliche zweite Eintrag in einer Liste
> von ausgeschriebenen oder abgekürzten Monatsnamen. Warum sollte man da
> mit einem leeren Element anfangen.

Man könnte ja auch einfach 1 abziehen. So wie es jetzt ist, muss man 
stattdessen 1 addieren, wenn man den Monat als Zahl ausgeben will.
Aber gut, das wurde halt mal so entschieden und ist jetzt eben so.