[lug-ld] S) Antw. signed long (Datum/Zeit) bearbeitet

[Pahle Heinz]

Liebe LUGer,
dabei Christian B. und Volker G.!

ZUM THEMA "Linux 32 Bit und long (32 Bit) Sekundenzähler in unsigned
long" KAM ZWAR NICHT DIE WUNSCHANTWORT "warum die Linuxwelt das nicht
schafft", ABER ANREGENDE BEITRÄGE.

Zu Christian:
Spätestens nach der Antwort von Dir war klar, dass ich als Programmierer
eines Versicherers keine Datum-Zeit-Angabe in einer long Var speichern
würde, sondern in einem String. Versicherung, guter Hinweis von Dir.
Schon vor vielen Jahren schaltete ich radikal zur Norm ISO 8601 um.
Datum/Zeit-Angaben nur noch so. Solch ein String ist nebenbei ASCII pur,
was dann auch zu 100 % UTF-8 ist.

Schaltsekunden sind bei Unix nicht eingeplant, bringt ja auch nichts.
Die Uhrzeit, z.B. jetzt, ist ein stures Multiplizieren der
Gregorianischen Kalender Daten, die alleine Schaltjahre berücksichtigen.

Der Vorzeichenaussage lt. Chaos-Radio, auf das Du hingewiesen hast,
glaube ich erst einmal nicht. Zweierkomplement ist zwar eine tolle
Erfindung, aber die braucht ein fortschreitender Zeitzähler gerade
nicht. Das etwas langatmige Gespräch beim Chaos-Radio werde ich mir mal
bei Haushaltdoof-Arbeit anhören, habe abgebrochen.

Zu Volker:
Du siehst, ich beherzige nicht nur Deinen Rat, ich mache es schon länger
so. Nur, bei Zeitdifferenzen(!) braucht es halt eine Integergröße und
wenn die ULONGLONG ist (MS). Man beachte das einleitende 'U'! Ich habe
damit keine Probleme, bleibe bei meinen 100ns-Intervallen seit
1601-01-01T00:00:00.
Deinen (Einlese-)Link habe ich angesehen, hatte ich so intus. Vor Jahren
habe ich die Unix-Sekunden bei Bilderbearbeitung genommen. Das taugt
aber nicht für Serienbilder, weil viel zu grob gerastert. Die Bildnummer
ist dann besser, oder dazu noch ms (z.B. Apple), was die Exif-Norm
zulässt. Ergo: Die Sekunden sind da mausetot. Als ich Deinen Text las
stutzte ich. Dein Format bezügl. SQL war nicht ISO 8601 kompatibel
geschrieben, z.B. fehlendes 'T' und '.' statt ':'. Nix für ungut - ich
stutzte halt (Erbsenzähler, Dippelschisser), dachte erst, ich hätte
etwas in der Norm übersehen.
NTPv4, Dein Tipp, meine Hausaufgabe, das in Sachen "Blick übern
Tellerrand". ich habe mal neugierig diagonal gelesen und siehe da,
erlösend: "It includes a 32-bit unsigned seconds field spanning 136
years (Anm. Heinz: ab 1970 bis 2106!) and a 32-bit fraction field
resolving 232 picoseconds (Anm. Heinz: totaler Pippikram)".
Also doch: Für die Jahre UNSIGNED 32 Bit!!! Aber gegenüber
Microsoft-Lösung 64-Bit ist das ZUM SCHREIEN RÜCKSTÄNDID, WEIL MAN WEGEN
PICO-SEKUNDEN DEN JAHRESUMFANG EINSCHRÄNKT. Das ist natürlich
theoretischer Natur, weil, siehe Christian: "Damit könnten zumindest
Deine Enkel oder Urenkel das nächste Problem erleben".

An alle:
Wenn sich eine Firma an die Datum-Zeit-Norm ISO 8601 halten will, dann
braucht man ja diese ISO-Norm. Wird die dann für ein Schweingeld
gekauft? Das Werk ist zwar umfangreich, aber die Info herausgezogen
(wahrscheinlich braucht man nur wenig daraus), was dann damit?
Ich fand das Dokument vor Jahren auf einem Rechner einer australischen
Uni - das dann "fer umme".

Kennt jemand einen Weg, wie man an teure ISO-Normen ohne Kosten herankommt?
Für mich umso wichtiger, weil ich damit ja keinen Gewinn erwirtschafte
und umlegen kann.
Das ist möglicherweise im Gegensatz zu Christian, der vielleicht das
Wein-Abfülldatum richtig schreiben muss, um einer Abmahnung zu entgehen.
Ich selbst muss noch nachsehen, ob die deutsche Schreibweise für Datum
dd.mm.yyyy noch Gültigkeit hat und wie lange noch.
Das Pfund ist ja auch noch aktuell, jedenfalls aus dem Munde meines
Bäckers. Daraufhin sollte man doch noch einen Schoppen(!) Pfälzer Wein
trinken :)
braucht, glaube ich, ein Dubbeglas.

Gruß
Heinz