Include - Quad-Timestamp

[Kaeru Gaman]

Helle hat recht!

[NicTheQuick]

Hoppla.

Da ich Stargates Funktionen "Konstantenlos" benutzt hatte und alle Stellen,
an denen 60 * 60 * 24 gerechnet wurde durch 84600 ersetzt hatte, ist
natürlich nichts passiert.

Hab den Code jetzt also angepasst.

[Little John]

xxx

[NicTheQuick]

Gerade die umgekehrte Funktion ist ja das Schwierige.
Einfach Datumsfunktionen, die nicht dem Unix Time Stamp folgen, habe ich
selbst schon gemacht. Siehe hier
Allerdings hatte ich da Probleme um Differenzen von Daten auszurechnen,
da man sie nicht einfach voneinander abziehen konnte.

[Kaeru Gaman]

was ist eigentlich mit dem Julianischen Datum?
warum wird das nicht verwendet?

[Little John]

Gerade die umgekehrte Funktion ist ja das Schwierige.

Ja, ist n bißchen schwieriger als diese Richtung.
Aber man braucht sowieso Funktionen für die Umrechnung in beiden Richtungen. Ich fang oft gern mit dem einfacheren an.

Einfach Datumsfunktionen, die nicht dem Unix Time Stamp folgen, habe ich
selbst schon gemacht. Siehe hier
Allerdings hatte ich da Probleme um Differenzen von Daten auszurechnen,
da man sie nicht einfach voneinander abziehen konnte.

Natürlich kann man das nicht ... Genau das ist ja der Hauptgrund, warum man eine Date()-Funktion benötigt. Die muss allerdings nicht genau wie bei PB funktionieren, es gibt auch andere Möglichkeiten. In jedem Fall ist der Zweck, Datumsangaben so umzucodieren, dass sie auf einer gleichmäßig fortlaufenden Skala abgebildet werden. Die Werte auf dieser Skala kann man dann addieren und subtrahieren. Danach kann man die Werte wieder ins Ausgangsformat zurückkonvertieren.

Gruß, Little John

[Little John]

Ich habe jetzt oben die Funktion SplitDateQ() hinzugefügt.

Gruß, Little John

[Little John]

was ist eigentlich mit dem Julianischen Datum?
warum wird das nicht verwendet?

Kommt immer drauf an wofür man das braucht. Ich hatte NicTheQuick so verstanden, dass er etwas haben wollte was kompatibel mit Date() usw. von PureBasic ist. Ich persönlich bevorzuge ja den Kalender der Französischen Revolution.
Hier ist eine schöne Seite mit einer Übersicht incl. Umrechnungsmöglichkeiten zwischen verschiedenen Kalendersystemen (engl.): Calendar Converter.

Gruß, Little John

[Kaeru Gaman]

ah, danke für den Link.

meine Frage war eher allgemein bezogen.
das Julianische Datum scheint mir das älteste und gebräuchlichste Format mit fortlaufender Tagesnummerierung zu sein.
da frage ich m ich, warum das nicht von vorne herein verwendet wurde,
sondern jeder OS-Hersteller wieder sein eigenes Süppchen kochen muss.

bei Microsoft kann ichs mir ja noch so erklären, dass 32bit einfach nicht groß genug war für ein weitreichenderen Datumsformat.
und zu der Zeit, wo die DOS geschrieben haben, gabs wohl noch keine 64bit Variablen,
jedenfalls nicht auf Rechnern die kleiner waren als 'ne Autowerkstatt.

[Little John]

DOS-Zeitangaben basieren ja auf 1980-01-01. Die Angaben wurden in 32 Bit gespeichert, 16 Bit für's Datum, 16 Bit für die Uhrzeit. Damit das passt, wurden nicht die Sekunden, sondern nur Int(Sekunden/2) gespeichert. Zeitstempel von Dateien unter DOS hatten daher immer eine gerade Anzahl von Sekunden.
Die 1970-01-01 beginnende Unix-Zeitrechnung ist da nicht viel besser als DOS, damit kann ich z.B. nicht ausrechnen an welchem Wochentag ich geboren wurde.
Der Windows-Dateistempel speichert übrigens in 64 Bit die Anzahl der 100ns-Intervalle (Nanosekunden!), die seit 1601-01-01 vergangen sind.

Es sieht mir auch so aus, dass oft nur ein Format für die eigenen Zwecke entwickelt wurde. Wie Du schon schreibst, denke ich auch dass der Hauptgrund im Computerbereich wohl früher die starke Begrenzung des Speicherplatzes war. Man vergisst das ja heute leicht. Z.B. hatte mein erster PC eine Festplatte mit 40 MB, das war damals Standard. Heute ist mein RAM über 50x so groß wie meine erste Festplatte!

Gruß, Little John