ISO 8601 Datum vergleichen

[DieDolly]

Wie vergleicht man am besten ein iso8601 Datum?
TDateTimes konvertiere ich vorher immer in Timestamps und habe dann was zum Rechnen.

[Luckie]

Warum nicht, wenn es funktioniert?

[DieDolly]

Das ist ein Int64. Ich wüsste ohnehin nicht wie man es sonst vergleichen sollte. Ich dachte nur es gibt eine vernünftigere Methode dafür.

[Uwe Raabe]

Wenn die Werte als String vorliegen, warum dann nicht direkt die Strings vergleichen? Das Format ist ja extra so aufgebaut, daß es dies ermöglicht. Das ist auf jeden Fall schneller als eine vorherige Konvertierung.

[DieDolly]

Es liegt als Int64 vor. Der Vergleich soll keinen allgemeinen Unterschied festellen, sondern welcher der beiden Werte älter oder neuer ist.

[Uwe Raabe]

Wenn es als Int64 vorliegt, wie ist dann die binäre Darstellung des Datums? ISO 8601 beschreibt ein reines Textformat.

[DieDolly]

Von binären Darstellungen habe ich keine Ahnung. Ich verstehe nicht einmal die Frage.
Wenn man das nicht als Int64 darstellen darf, wie soll man dann prüfen welcher davon neuer ist?

[Redeemer]

Warum konvertierst du TDateTime in Timestamp? Man kann auch TDateTime vergleichen, die korrekte Art und Weise ist mit DateUtils.

[himitsu]

Direkte Vergleiche der gespeicherten Ausgangswerte ist zu 99.9999999% immer schneller, als eine vorherige Umrechnung, bei jedem einzelnen Wert/Vergleich.

Ausnahme bei Anzahl an Vergleiche, welche die Anzahl der Werte stark überschreite. (alles mit allem Vergleichen, Sortieren usw.)
Aus diesem Grund legen Datenbanken auch einen Index an, in dem die Daten in einem optimaleren Format vorliegen.

z.B. einen Wert in einer Liste suchen und überall erst umrechnen zu müssen ist natürlich langsamer, als wenn die Daten bereits in einem "optimalen" Format vorliegen, bzw, vorher umgewandelt wurden. (z.B. Integer bzw. Int64 anstatt vieler langer Strings ... ein orinaler Vergleich gegenüber dem Vergleich vieler kleiner Chars pro Wert)

[Uwe Raabe]

Zitat:

Zitat von DieDolly (Beitrag 1460329)

Von binären Darstellungen habe ich keine Ahnung. Ich verstehe nicht einmal die Frage.
Wenn man das nicht als Int64 darstellen darf, wie soll man dann prüfen welcher davon neuer ist?

Die Frage geht doch auf ISO 8601 und das ist ein Textformat für Datum und Uhrzeit. Mit Int64 hat das gar nichts zu tun. Wenn du also sagst, daß du ISO 8601 Daten als Int64 hast, dann ergibt diese Aussage erstmal keinen Sinn.

Weiterhin ist das ISO 8601 Format bewusst so aufgebaut, daß ein direkter Stringvergleich möglich ist.

Vielleicht wäre jetzt ein guter Zeitpunkt deinen bisherigen Code zu zeigen?

[DieDolly]

Zitat:

Vielleicht wäre jetzt ein guter Zeitpunkt deinen bisherigen Code zu zeigen?

Es gibt keinen? Deswegen frage ich doch hier.

Also kann man das alles als String lassen und so vergleichen? Wie vergleicht man dann ein Datum 1 und ein Datum 2?

Der Hintergrund ist ganz einfach: ich speichere aktuell verschiedene Werte als Timestamp. Und irgendwann demnächst ist der halt... zu Ende und würde überlaufen.
Deswegen möchte ich das schon frühzeitig alles abändern.
Ich vergleiche sehr oft Werte wie "Datum 1 > Datum 2" und rechne das vorher in Integer/Sekunden.

Oder sollte man intern nur mit TDateTime arbeiten und vergleichen und nur zum Speichern das lange Format nehmen?
Man lädt das Format ein, konvertiert es einmalig in TDateTime um und das wars.

[Luckie]

Wenn Datum 1 und Datum 2 als ISO 8601 vorliegen, kannst du sie genauso, wie Strings, vergleichen. Wo ist jetzt dein Problem oder Frage?

[p80286]

Das ISO-Datum in seiner vollen Ausprägung hat ja auch noch einen Zeit-Anteil incl. Zeitzone das ist dann etwas unübersichtlicher. TDatetime oder ein Timestamp sind immer vollständig, liegt es daran? Welche Daten liegen denn vor?

Gruß
K-H

[Sherlock]

Zitat:

Zitat von DieDolly (Beitrag 1460336)

Der Hintergrund ist ganz einfach: ich speichere aktuell verschiedene Werte als Timestamp. Und irgendwann demnächst ist der halt... zu Ende und würde überlaufen.

Nein. Jedenfalls nicht zu unseren Lebzeiten, es sei denn, Du hast ein eigenes Timestamp erfunden und nutzt darin SmallInt um Sekunden seit 01.01.2020 darzustellen :lol:. Seit man bis 2038 gedacht hat, haben Unix-Timestamps int64 als Datentyp... das reicht.

Sherlock

[DieDolly]

Heißt das die 2038 Grenze gibt es nicht mehr?

[himitsu]

Doch, aber nur wenn die Variable in 31 Bit vorliegt.
Und wenn doch, dann ist immernoch lange Zeit. (der Klimawandel ertränkt uns eh vorher)

Integer springt 2038 ins Negative und mit einem Unsigned-Integer hast sogar noch bis 2106 deine Ruhe.
* ab 2038 Probleme mit Integer-Vergleichen
* ab 2106 Datenverlust, bzw. Sprung in die Vergangenheit (1970), weil zuwenige Bit

[DieDolly]

Ich stelle alles auf 64bit Integer um das sollte erstmal reichen. Oder Cardinal? :lol:

[p80286]

Wenn Du keine negativen Timestamps benötigen solltest ist unsignedInt wohl Mittel der Wahl.

Gruß
K-H