Esiste una costante per "fine del tempo"?

Chiediti perché hai bisogno di una variabile del genere in primo luogo.

Molto probabilmente, stai mentendo sui tuoi dati: ogni volta che hai bisogno di una variabile "fine del tempo", non ti stai riferendo alla fine effettiva del tempo; piuttosto stai esprimendo cose come "non esiste limite superiore per questa data", "questo evento continua indefinitamente" o simili.

La soluzione corretta, quindi, è esprimere direttamente questi intenti invece di fare affidamento su un valore magico: usa tipi di date nullable (dove null indica "nessuna data di fine impostata"), aggiungi un campo booleano "indefinito", usa un wrapper polimorfico (che può essere una data reale o uno speciale valore "indefinito") o qualsiasi altra cosa il tuo linguaggio di programmazione possa offrire.

Ovviamente, la soluzione corretta non è sempre fattibile, quindi potresti finire con l'usare un valore magico dopotutto, ma quando lo fai, devi decidere un valore adatto per ogni caso, perché quali date fanno e non ha senso dipende dal dominio che stai modellando - se stai memorizzando i timestamp dei log, il 01/01/2999 è una ragionevole "fine del tempo"; le probabilità che la tua applicazione sia ancora utilizzata da quasi 1000 anni sono, a mio avviso, praticamente pari a zero. Considerazioni simili vanno fatte per le applicazioni di calendario. Ma cosa succederebbe se il tuo software gestisse dati scientifici, ad esempio, previsioni a lungo termine sul clima della Terra? Quelli potrebbero in realtà voler guardare mille anni nel futuro. O fai un ulteriore passo avanti; l'astronomia, un campo in cui è perfettamente normale ragionare in tempi molto lunghi dell'ordine di miliardi di anni, sia sul sentiero che sul futuro. Per quelli, 01/01/2999 è un massimo arbitrario perfettamente ridicolo. OTOH, un sistema di calendario che è in grado di gestire i tempi di dieci trilioni di anni nel futuro non è pratico per un sistema di monitoraggio degli appuntamenti dei dentisti, se non altro per la capacità di archiviazione.

In altre parole, non esiste un'unica scelta migliore per un valore che è sbagliato e arbitrario per definizione per cominciare. Questo è il motivo per cui è davvero raro vederne uno definito in qualsiasi linguaggio di programmazione; quelli che di solito non lo chiamano "fine del tempo", ma piuttosto qualcosa come DATE_MAX (o Date.MAX ), e prendilo per indicare "il più grande valore che può essere memorizzato nel tipo di dati data", non " la fine del tempo "o" indefinitamente ".

Come industria siamo stati notoriamente miopi e arbitrari nella ricerca del salvataggio di pochi byte, ad es.

• 31 dic 99
• 19 gennaio 2038
• T + 50 anni, quando si spera che tutti i sistemi in cui sono stato coinvolto siano diventati defunti o siano stati sostituiti (o sono morto, a seconda di cosa viene prima).

IMHO la soluzione migliore è stare con un livello appropriato e corrente di astrazione su "data massima" e sperare che una soluzione comune abbia risolto il problema prima che arrivi il momento.

es. in .NET, DateTime.MaxValue è arbitrariamente 23:59:59.9999999, December 31, 9999, exactly one 100-nanosecond tick before 00:00:00, January 1, 10000 . Quindi, se le mie supposizioni sulla mia longevità sono false e arriva l'anno 10000, spero piuttosto che una ricompilazione della mia app con una versione successiva del framework estenda DateTime.MaxValue (ad es. Cambiando il suo tipo sottostante) ad un nuovo valore arbitrario e lanciare il problema più in là per altri millenni.

Modifica

(Rafforzando il punto di tdammers che piuttosto che confondere una data artificiale, è più corretto evidenziare esplicitamente il fatto al consumatore che non abbiamo una data di fine.)

In alternativa all'utilizzo di null , che ha la conseguenza negativa di essere compatibile con qualsiasi tipo di riferimento (incluso .Net Nullable '), che probabilmente causerà problemi NRE nei consumatori che dimenticano di controllare, nei linguaggi FP, è normale utilizzare un wrapper Opzione o Forse tipo attorno a un valore che può o non può essere restituito.

Pseudo codice:

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

Il vantaggio di fare questo è che costringe il consumatore a ragionare su entrambi i casi. La corrispondenza dei pattern è anche comune qui:

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

Probabilmente vuoi un algebraic data type con la variante per il grande% infinito% co_de. Quindi definisci il confronto, in cui date variant sarà sempre più grande di qualsiasi altro infinite .

Esempio 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

link

Memorizza i tuoi tempi come un numero in virgola mobile a doppia precisione IEE754 a 64 bit e puoi utilizzare +INF . Non utilizzare la precisione singola, solo 7 cifre precise e un po 'basse per una data.

Cocoa / Objective-C ha metodi factory [NSDate distantPast] e [NSDate distantFuture] che rappresentano esattamente il tipo di cosa a cui ti stai riferendo.

I valori restituiti dall'implementazione corrente sono costanti che rappresentano circa 0 AD e 4000 AD, sebbene questi non siano garantiti o documentati.

Generalmente non esiste un valore tale, perché non sarebbe utile come costrutto linguistico.

MAX_INT ed è parente di tutti servono a uno scopo. Possono essere utilizzati nel tuo codice per controllare gli overflow. Ciò è utile se si intende creare e gestire oggetti di dati di grandi dimensioni in array, vettori o altro. È anche un valore abbastanza specifico per la piattaforma.

Il caso d'uso per un valore MAX_DATE è più difficile da vedere. Tipicamente questi sono solo valori, non sono usati come parte della struttura del programma, e quindi il valore che gira intorno non avrebbe conseguenze disastrose per il programma (anche se potrebbe riguardare i dati). Inoltre, i tipi di data e ora in C, C ++ ecc. Sono di solito definiti più rigorosamente; e così le persone che scrivono il programma non devono preoccuparsi che possa cambiare tra piattaforme.

Su un progetto che abbiamo fatto, abbiamo avuto una situazione in cui il dimensionamento di alcuni database è stato fatto in un modo che non sarebbe stato sostenibile dopo 30 anni di utilizzo del software. Quando il cliente chiese al nostro ingegnere capo in quel momento: "Bene, cosa faremo dopo 30 anni di utilizzo del software?" Il nostro ingegnere capo, fresco come un cetriolo, rispose con una scrollata di spalle: "Andremo a bere una birra!"

Il punto è, basta usare la data che è abbastanza lontana in futuro. Probabilmente il tuo software verrà aggiornato o sostituito da allora. :)