Umwandlung von UTC-Zeit in Unix-Zeit selbst gemacht

[Matthias S. (fx00013)]

Hi,
um dem Quellcode (für's Arduino Board) möglichst klein und kompakt zu 
halten, versuche ich möglichst auf Bibliotheken zu verzichten.
Von daher suche ich nun nach einer Lösung, wie ich aus den Daten 
(seconds, minutes, hours, day, date, month, year), welche ich per I2C 
vom DS1307 erhalte, einen Unix-Zeit-Wert zu ermitteln.

Auf Wikipedia ( http://de.wikipedia.org/wiki/Unixzeit ) steht eine 
Beispielsfunktion, welche (eigentlich) meine Problematik lösen sollte. 
Leider erhalte ich von dieser Funktion nicht den richtigen Wert :(

Per Google finde ich nur irgendwelche Onlineumrechner :/

Muss ich nun tatsächlich die Time.h Library einfügen, nur damit ich die 
aktuelle Zeit in der Unix-Schreibweise erhalte?


So weit,
Matthias

[René (Gast)]

Kannst du falsch etwas genauer definieren?

Grüsse,
R.

[Matthias S. (fx00013)]

Ausschnitt aus der aktuellen Ausgabe:

18.6.2013 22:13:29  1356979081
18.6.2013 22:13:30  1356979082
18.6.2013 22:13:31  1356979083
18.6.2013 22:13:32  1356979084
18.6.2013 22:13:33  1356979085
18.6.2013 22:13:34  1356979086
18.6.2013 22:13:35  1356979087
18.6.2013 22:13:36  1356979088
18.6.2013 22:13:37  1356979089
18.6.2013 22:13:38  1356979090
18.6.2013 22:13:39  1356979091
18.6.2013 22:13:40  1356979092
18.6.2013 22:13:41  1356979093
18.6.2013 22:13:42  1356979094
18.6.2013 22:13:43  1356979095
18.6.2013 22:13:44  1356979096
18.6.2013 22:13:45  1356979097

Hinten ist jeweils der Zeitstempel von der Uhrzeit zu sehen. Also der 
Zeitstempel, den die Funktion von Wikipedia zurückgibt.
Angenommen wir nehmen nun den letzten Wert und geben ihn in einen 
Umrechner ein:

das datum von 1356979097 lautet: 31.12.2012 - 19:38:17

:/

[Karl H. (kbuchegg)]

Matthias S. schrieb:

> Auf Wikipedia ( http://de.wikipedia.org/wiki/Unixzeit ) steht eine
> Beispielsfunktion, welche (eigentlich) meine Problematik lösen sollte.
> Leider erhalte ich von dieser Funktion nicht den richtigen Wert :(

Der Code

unix_zeit=sekunde + 60*minute + 60*60*stunde +
    (tage_seit_jahresanfang[monat-1]+tag-1)*60*60*24 +
    (jahre*365+schaltjahre)*60*60*24;

ist ganz offensichtlich für eine Maschine geschrieben, bei der ein int 
32 Bit groß ist. (60*60*24 ist für einen 16-Bit int viel zu groß)
Wenn du das berücksichtigst und den Code entsprechend umbaust, dass bei 
dir alles in long gerechnet werden muss (= ebenfalls 32 Bit), sollte es 
da eigentlich keine Probleme geben.
Zumal die Definition der Unix-Zeit (Sekunden ab dem. 1.1.1970) ja nun 
wirklich keine Raketentechik ist und man versehentliche Fehler leicht 
raustesten kann.

[René (Gast)]

Das scheint lediglich ein Offset Fehler zu sein. Du wirst nicht umhin 
kommen die Werte aus den Arrays zu prüfen resp. nachzurechnen. 
Grundsätzlich sollte die Funktion so gehen.

Grüsse,
R.

[René (Gast)]

Karl Heinz Buchegger schrieb:
> Zumal die Definition der Unix-Zeit (Sekunden ab dem. 1.1.1970) ja nun
> wirklich keine Raketentechik ist.

1969 war das Raketentechnik :-)

[Karl H. (kbuchegg)]

Karl Heinz Buchegger schrieb:

> Wenn du das berücksichtigst und den Code entsprechend umbaust, dass bei
> dir alles in long gerechnet werden muss (= ebenfalls 32 Bit), sollte es
> da eigentlich keine Probleme geben.

Wenn ich mir das ansehe, dann geht es im wesentlichen darum, dass man 
ein paar Datentypen anpassen muss, bzw. den Zahl-Literalen mit einem 
Suffix auf die Sprünge hilft. Nichts was einem C Programmierer groß 
aufstossen oder vor Probleme stellen sollte. Jeder der Code von woanders 
übernimmt steht immer wieder vor dem Problem: wie groß ist eigentlich 
ein int? Was ist die Annahme im vorliegenden Code?

FAQ: Datentypen in Operationen

[Jörg W. (dl8dtl) (Moderator)]

Matthias S. schrieb:
> Hi, um dem Quellcode (für's Arduino Board) möglichst klein und kompakt
> zu halten, versuche ich möglichst auf Bibliotheken zu verzichten.

Was hat das eine mit dem anderen zu tun?

Wenn du zugunsten eigenen Codes auf den aus der avr-libc verzichten
würdest, dann wette ich, dass du in vielen Fällen größeren und
schlechteren Objektcode hättest, und Quellcode sparst du beim
Verzicht auf die Benutzung von Bibliotheken nun gleich gar nicht ein.

avr-libc hat mittlerweile (im SVN, noch nicht in einem Release) eine
recht umfängliche und vollständige time-Unterbibliothek.  Deren
Quellcode kannst du natürlich auch schon vorab in eigenene Applikationen
benutzen, dafür ist es ja Opensource.

[Matthias S. (fx00013)]

Wow krass ... Mit so schnellen Reaktionen habe ich nicht gerechnet :)
Das das Arduino Uno für ints nur 16bit verwendet, war mir neu.
Habe die Funkion angepasst. Nun läufts. Super und großen Dank :)

[Konrad S. (maybee)]

Und wenn es genau werden soll:
http://de.wikipedia.org/wiki/Schaltsekunde

[Oliver (Gast)]

Matthias S. schrieb:
> Das das Arduino Uno für ints nur 16bit verwendet, war mir neu.

Das ist eine Eigenschaft des avr-gcc, und kein Problem des "Arduino Uno"

Oliver

[Detlef _. (detlef_a)]

Wo wir gerade beim Thema sind:

Kennt jemand ne C-Source für die Umkehrfkt., also unixzeit zu 
Tag/Stunde/Minute/Sekunde ?

THX
Cheers
Detlef

[Jörg W. (dl8dtl) (Moderator)]

Detlef _a schrieb:
> Kennt jemand ne C-Source für die Umkehrfkt., also unixzeit zu
> Tag/Stunde/Minute/Sekunde ?

Schau dir doch bitte mal die aktuelle avr-libc an (im SVN).

[Detlef _. (detlef_a)]

Yo, hab 1.8.0 gezogen.
Finde nix, wo muß ich denn kucken?

THX.

Cheers
Detlef

[Malte S. (maltest)]

Jörg Wunsch schrieb:
> Schau dir doch bitte mal die aktuelle avr-libc an (im SVN).

Detlef _a schrieb:
> Yo, hab 1.8.0 gezogen.

Das ist die Release, nicht die SVN-Version. Hint: 
http://svn.savannah.nongnu.org/viewvc/trunk/avr-libc/libc/time/?root=avr-libc
z.B. gmtime_r.c

[W.S. (Gast)]

Matthias S. schrieb:
> Von daher suche ich nun nach einer Lösung, wie ich aus den Daten
> (seconds, minutes, hours, day, date, month, year), welche ich per I2C
> vom DS1307 erhalte, einen Unix-Zeit-Wert zu ermitteln.

Gegenfrage: wozu brauchst du denn diese Unix-Zeit?

Gerade wenn es ne eher kleine Maschine ist, sollte man besser mit 
getrennten Zählern für die Tageszeit und das Datum arbeiten. Ist 
effektiver, weil man dort keine 32 Bit Arithmetik in HW hat. Obendrein 
braucht man oftmals kein Datum vor dem jahr 2000.

Denk also mal eher nach darüber, zu welchen Zwecken du Datum und Uhrzeit 
brauchst. Ich mach es bei meinem Zeug meist so, daß ich den Systemtick 
als Uhrzeit (dword) benutze (FR oder ARM) und um Mitternacht das Datum 
inkrementiere und den Systemtick nulle. Nur für Dinge, bei denen keine 
feine Auflösung nötig ist, verwende ich die Anzahl Sekunden ab 1.1.2000


Karl Heinz Buchegger schrieb:
> ist ganz offensichtlich für eine Maschine geschrieben, bei der ein int
> 32 Bit groß ist.

Ach, Karlheinz... Zitat aus der angegebenen Quelle:
 long unix_zeit;

und das sollte reichen, um unseren TO auf die richtige Datenbreite 
hinzuweisen.

W.S.

[Malte S. (maltest)]

Je nachdem wie lange dein Device laufen soll, bedenke bitte das 
http://de.wikipedia.org/wiki/Jahr-2038-Problem :)

$ gcc -x c -o time - && ./time

#include <time.h>
#include <stdio.h>

int main() {
    printf("%lu\n", sizeof(time_t));
}

8

[Karl H. (kbuchegg)]

W.S. schrieb:

> Ach, Karlheinz... Zitat aus der angegebenen Quelle:
>  long unix_zeit;
>
> und das sollte reichen, um unseren TO auf die richtige Datenbreite
> hinzuweisen.

Das hat noch lange nichts damit zu tun, ob eine Berechnung

  60*60*24

überläuft oder nicht.
Auf einem System, auf dem ein int 16-Bit breit ist, tut sie es. Auf 
einem System, auf dem ein int 32-Bit breit ist, tut sie es nicht.
Und viele C-Programmierer sehen solche Dinge einfach nicht, weil für sie 
die Vorstellung, dass auch Konstante einen Datentyp haben, etwas 
'esoterisches' an sich hat, das sie gerne ignorieren.

[W.S. (Gast)]

Karl Heinz Buchegger schrieb:
> Und viele C-Programmierer sehen solche Dinge einfach nicht,

Jaja, geb ich dir ja voll Recht.

Der TO hätte sich vorher nen Gedanken machen sollen. Es hätte auch 
ausgereicht, nicht den ganzen Krempel in eine einzige Anweisung zu 
quetschen, sondern gemütlich Stück für Stück den long zusammenzusetzen. 
Der Compiler kann es ja auch nur so machen.

Wollen wir jetzt gemeinsam auf die Doofheit des Nachwuchses schimpfen 
oder doch lieber noch schnell was zum Grillen einkaufen oder wenigstens 
ein Bier aus'm Keller holen und auf besseres Wetter hoffen? ;-)

W.S.