Gibt es eine Konstante für "End of Time"?

Bei einigen Systemen wird der Zeitwert 9999-12-31 als "Ende der Zeit" als das Ende der Zeit verwendet, die der Computer berechnen kann. Aber was ist, wenn es sich ändert? Wäre es nicht besser, diese Zeit als eingebaute Variable zu definieren?

In C und anderen Programmiersprachen gibt es normalerweise eine Variable wie MAX_INToder eine ähnliche, um den größten Wert zu erhalten, den eine Ganzzahl haben könnte. Warum gibt es keine ähnliche Funktion, um MAX_TIMEzB die Variable auf das "Ende der Zeit" zu setzen, was für viele Systeme normalerweise 9999-12-31 ist? Um das Problem der Hardcodierung auf ein falsches Jahr (9999) zu vermeiden, könnten diese Systeme eine Variable für das "Ende der Zeit" einführen?

** Reales Beispiel **

End of validity date: 31/12/9999.(offizielle Dokumente sind wie folgt aufgelistet) Der Blogger möchte eine Seite schreiben, die immer oben ist, die Begrüßungsseite. Es wird also so weit wie möglich in die Zukunft verabredet:

3000? Ja, die Begrüßungsseite, mit der Sie konfrontiert sind, wird am 1. Januar 3000 gepostet. Diese Seite wird also für immer oben im Blog geführt =) Sie wurde tatsächlich am 31. August 2007 gepostet.

Fragen Sie sich, warum Sie überhaupt eine solche Variable benötigen.

Höchstwahrscheinlich lügen Sie über Ihre Daten: Wenn Sie eine Variable für das Ende der Zeit benötigen, beziehen Sie sich nicht auf das tatsächliche Ende der Zeit. Vielmehr drücken Sie Dinge wie "Es gibt keine Obergrenze für dieses Datum", "Dieses Ereignis wird auf unbestimmte Zeit fortgesetzt" oder Ähnliches aus.

Die richtige Lösung besteht also darin, diese Absichten direkt auszudrücken, anstatt sich auf einen magischen Wert zu verlassen: Verwenden Sie nullfähige Datentypen (wobeinull "no end date set" angibt), fügen Sie ein "unbestimmtes" boolesches Feld hinzu, und verwenden Sie einen polymorphen Wrapper (der dies kann) entweder ein echtes Datum oder ein spezieller "unbestimmter" Wert sein) oder was auch immer Ihre Programmiersprache zu bieten hat.

Natürlich ist die richtige Lösung nicht immer realisierbar, so dass Sie möglicherweise doch einen magischen Wert verwenden, aber wenn Sie dies tun, müssen Sie sich im Einzelfall für einen geeigneten Wert entscheiden, da die Daten dies tun und nicht tun Der Sinn hängt von der Domain ab, die Sie modellieren. Wenn Sie Protokollzeitstempel speichern, ist der 01.01.1999 ein angemessenes "Ende der Zeit". Die Chancen, dass Ihre Anwendung in fast 1000 Jahren noch verwendet wird, sind meiner Meinung nach praktisch Null. Ähnliche Überlegungen gelten für Kalenderanwendungen. Aber was ist, wenn Ihre Software wissenschaftliche Daten verarbeiten soll, zum Beispiel langfristige Vorhersagen über das Erdklima? Diese möchten vielleicht tatsächlich tausend Jahre in die Zukunft schauen. Oder gehen Sie noch einen Schritt weiter. Astronomie, ein Bereich, in dem es völlig normal ist, in sehr großen Zeiträumen in der Größenordnung von Milliarden von Jahren zu argumentieren, sowohl in den Weg als auch in die Zukunft. Für diese ist der 01.01.1999 ein völlig lächerliches willkürliches Maximum. OTOH, ein Kalendersystem, das in der Lage ist, Zeitspannen von zehn Billionen Jahren in die Zukunft zu bewältigen, ist für ein Terminverfolgungssystem für Zahnärzte schon wegen der Speicherkapazität kaum praktikabel.

Mit anderen Worten, es gibt keine einzige beste Wahl für einen Wert, der per Definition falsch und willkürlich ist. Aus diesem Grund ist es wirklich ungewöhnlich, eine in einer Programmiersprache definierte Sprache zu sehen. diejenigen, die es normalerweise nicht als "Ende der Zeit", sondern als "den größten Wert, der im Datums-Datentyp gespeichert werden kann" bezeichnen DATE_MAX(oder Date.MAX), und nicht als "das Ende der Zeit" oder "das Ende der Zeit" "unbegrenzt".

Als Industrie sind wir notorisch kurzsichtig und willkürlich, um ein paar Bytes zu sparen, z

• 31. Dezember 99
• 19. Januar 2038
• T + 50 Jahre, in denen hoffentlich alle Systeme, an denen ich beteiligt war, ausgefallen oder ersetzt wurden (oder ich bin tot, je nachdem, was zuerst eintritt).

Meines Erachtens ist es am besten, eine angemessene, allgemein gültige Abstraktionsebene für das "maximale Datum" beizubehalten und zu hoffen, dass eine gemeinsame Lösung das Problem behoben hat, bevor es soweit ist.

zB in .NET ist DateTime.MaxValue beliebig 23:59:59.9999999, December 31, 9999, exactly one 100-nanosecond tick before 00:00:00, January 1, 10000. Wenn also meine Vermutungen über meine eigene Lebensdauer falsch sind und das Jahr 10000 bevorsteht, hoffe ich eher, dass sich eine Neukompilierung meiner App mit einer späteren Version des Frameworks fortsetztDateTime.MaxValue (z. B. durch Ändern des zugrunde liegenden Typs) auf einen neuen beliebigen Wert ausgedehnt wird und das Problem noch ein paar Jahrtausende später angehen.

Bearbeiten

(Dies unterstreicht, dass es richtiger ist, dem Verbraucher explizit darauf hinzuweisen, dass wir kein Enddatum haben, als ein künstliches Datum zu täuschen.)

Als Alternative zur Verwendung null, die die negative Konsequenz hat, typkompatibel mit jedem Referenztyp zu sein (einschließlich .Net Nullable`), was wahrscheinlich NRE-Probleme bei Verbrauchern hervorruft, die vergessen haben, in FP-Sprachen zu prüfen, ist es üblich, ein zu verwenden Option oder Vielleicht Geben Sie einen Wrapper um einen Wert ein, der möglicherweise oder möglicherweise nicht zurückgegeben wird.

Pseudocode:

Option<DateTime> LeaseExpiryDate(Home rental) 
{
    if (... expiry date can be determined ...)
       return Some(rental.ExpiryDate);
    else
       return None;
}

Dies hat den Vorteil, dass der Verbraucher in beiden Fällen zum Nachdenken gezwungen wird. Pattern Matching ist auch hier an der Tagesordnung:

LeaseExpiryDate(myHome) match {
     case Some(expiryDate) => "Expired"
     case None => "No Expiry"
}

Du willst wahrscheinlich eine algebraic data typemit Variante für unendlich groß date. Definieren Sie dann den Vergleich, bei dem die infiniteVariante immer größer als jede andere ist date.

Beispiel in Scala:

sealed abstract class SmartTime extends Ordered[SmartTime] { x =>
        def compare(y: SmartTime) = {
                x match {
                        case InfiniteFuture => 1
                        case InfinitePast => -1
                        case ConcreteTime(x) =>
                                y match {
                                        case InfiniteFuture => -1
                                        case InfinitePast => 1
                                        case ConcreteTime(y) => x compare y
                                }
                }
        }
}
case class ConcreteTime(t: Long) extends SmartTime
case object InfiniteFuture extends SmartTime
case object InfinitePast extends SmartTime

http://ideone.com/K5Kuk

Speichern Sie Ihre Zeiten als 64-Bit-Gleitkommazahl nach IEE754 mit doppelter Genauigkeit, und Sie können sie verwenden +INF. Verwenden Sie keine einfache Genauigkeit, das ist nur eine Genauigkeit von 7 Stellen, was für ein Datum etwas niedrig ist.

Cocoa / Objective-C verfügt über Factory-Methoden [NSDate distantPast] und [NSDate distantFuture], die genau das darstellen, worauf Sie sich beziehen.

Die von der aktuellen Implementierung zurückgegebenen Werte sind Konstanten, die circa 0 AD und 4000 AD darstellen, obwohl diese nicht garantiert oder dokumentiert sind.

Es gibt im Allgemeinen keinen solchen Wert, da er als Sprachkonstrukt nicht nützlich wäre.

MAX_INTund es ist verwandt, alle dienen einem Zweck. Sie können in Ihrem Code verwendet werden, um auf Überläufe zu prüfen. Dies ist nützlich, wenn Sie große Datenobjekte in Arrays, Vektoren usw. erstellen und verwalten möchten. Es ist auch ein ziemlich plattformspezifischer Wert.

Der Anwendungsfall für einen MAX_DATEWert ist schwieriger zu erkennen. In der Regel handelt es sich hierbei nur um Werte, die nicht als Teil der Programmstruktur verwendet werden. Daher hätte das Umkreisen von Werten keine katastrophalen Folgen für das Programm (obwohl dies möglicherweise für die Daten der Fall ist). Außerdem sind die Datums- und Zeittypen in C, C ++ usw. in der Regel strenger definiert. Die Leute, die das Programm schreiben, müssen sich also keine Sorgen machen, dass es sich zwischen den Plattformen ändern könnte.

Bei einem unserer Projekte hatten wir eine Situation, in der die Größe einiger Datenbanken so festgelegt wurde, dass sie nach 30 Jahren mit der Software nicht mehr nachhaltig waren. Als der Kunde unseren damaligen leitenden Ingenieur fragte: "Nun, was machen wir nach 30 Jahren mit Ihrer Software?" Unser leitender Ingenieur, cool wie eine Gurke, antwortete mit einem Achselzucken: "Wir gehen und trinken ein Bier!"

Der Punkt ist, verwenden Sie einfach das Datum, das in der Zukunft weit genug ist. Möglicherweise wird Ihre Software bis dahin aktualisiert oder ersetzt. :)