Esiste una costante per la "fine dei tempi"?

Per alcuni sistemi, il valore temporale 9999-12-31 viene utilizzato come "fine dei tempi" come la fine dei tempi che il computer può calcolare. Ma cosa succede se cambia? Non sarebbe meglio definire questa volta una variabile incorporata?

In C e in altri linguaggi di programmazione di solito esiste una variabile come MAX_INTo simile per ottenere il valore più grande che un intero possa avere. Perché non esiste una funzione simile per MAX_TIMEesempio impostare la variabile sulla "fine dei tempi" che per molti sistemi di solito è 9999-12-31. Per evitare il problema dell'hardcoding per un anno sbagliato (9999), questi sistemi potrebbero introdurre una variabile per la "fine dei tempi"?

** Esempio reale **

End of validity date: 31/12/9999.(i documenti ufficiali sono elencati in questo modo) Il blogger vuole scrivere una pagina sempre in primo piano, la pagina di benvenuto. Quindi viene data una data il più lontano possibile in futuro:

3000? Sì, la pagina di benvenuto che stai affrontando è pubblicata il 1 ° gennaio 3000. Quindi questa pagina sarà mantenuta per sempre nella parte superiore del blog =) In realtà è stata pubblicata il 31 agosto 2007.

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

Molto probabilmente, stai mentendo sui tuoi dati: ogni volta che hai bisogno di una variabile di "fine dei tempi", non ti riferisci alla fine dei tempi effettivi; piuttosto stai esprimendo cose come "non c'è limite superiore per questa data", "questo evento continua indefinitamente" o simili.

La soluzione corretta, quindi, è esprimere questi intenti direttamente invece di fare affidamento su un valore magico: usa tipi di data nullable (dove nullindica "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 qualunque cosa il tuo linguaggio di programmazione abbia da offrire.

Naturalmente, la soluzione corretta non è sempre fattibile, quindi potresti finire per usare un valore magico dopo tutto, ma quando lo fai, devi decidere su un valore adatto in base al caso, perché quali date fanno e non ha senso dipende dal dominio che stai modellando: se stai memorizzando i timestamp dei log, 01/01/2999 è una ragionevole "fine dei tempi"; le probabilità che la tua applicazione continui a essere utilizzata tra quasi 1000 anni da adesso sono, credo, praticamente zero. Considerazioni simili valgono per le applicazioni di calendario. E se il tuo software gestisse dati scientifici, ad esempio previsioni a lungo termine sul clima terrestre? Quelli potrebbero effettivamente voler guardare mille anni nel futuro. O fai un passo avanti; l'astronomia, un campo in cui è perfettamente normale ragionare in intervalli di tempo molto grandi dell'ordine di miliardi di anni, sia nel percorso che nel futuro. Per quelli, 01/01/2999 è un massimo arbitrario perfettamente ridicolo. OTOH, un sistema di calendario che è in grado di gestire intervalli di dieci trilioni di anni nel futuro non è praticamente pratico per un sistema di monitoraggio degli appuntamenti del dentista, se non altro per la capacità di archiviazione.

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

Come industria siamo stati notoriamente miopi e arbitrari nel tentativo di salvare qualche 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 sostituiti (o sono morto, a seconda dell'evento che si verifica per primo).

La scommessa migliore di IMHO è quella di rimanere con un livello di astrazione adeguato e tradizionale alla "data massima", e spero che una soluzione comune abbia risolto il problema prima che arrivi il tempo.

ad 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 i miei presupposti sulla mia longevità sono falsi e arriva l'anno 10000, spero piuttosto che una ricompilazione della mia app con una versione successiva del framework si estenda DateTime.MaxValue(ad esempio modificando il tipo sottostante) a un nuovo valore arbitrario e calciare il problema più avanti per altri millenni.

modificare

(Rafforzare i tdammer sottolinea che, anziché confondere una data artificiale, è più corretto evidenziare esplicitamente al consumatore che non abbiamo una data di fine.)

In alternativa all'uso null, che ha la conseguenza negativa di essere compatibile con qualsiasi tipo di riferimento (incluso .Net Nullable`), che probabilmente causerà problemi di NRE nei consumatori che dimenticano di controllare, nei linguaggi FP, è normale usare un Opzione o Forse digitare wrapper 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 del modello è anche qui comune:

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

Probabilmente vuoi una algebraic data typevariante con infinito grande date. Quindi definire il confronto, in cui la infinitevariante sarà sempre più grande di qualsiasi altra date.

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

http://ideone.com/K5Kuk

Memorizza i tuoi tempi come un numero a virgola mobile IEE754 a 64 bit a doppia precisione e puoi usarlo +INF. Non usare la precisione singola, è preciso solo a 7 cifre, un po 'basso per una data.

Cocoa / Objective-C ha metodi di fabbrica [NSDate distantePast] e [NSDate distanteFuture] che rappresentano esattamente il tipo di cosa a cui ti riferisci.

I valori restituiti dall'attuale implementazione sono costanti che rappresentano circa 0 d.C. e 4000 d.C., sebbene non siano garantiti o documentati.

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

MAX_INTed è parente tutti hanno uno scopo. Possono essere utilizzati nel tuo codice per verificare gli overflow. Ciò è utile se si stanno creando e gestendo oggetti di dati di grandi dimensioni in array, vettori o altro. È anche un valore abbastanza specifico per la piattaforma.

Il caso d'uso di un MAX_DATEvalore è più difficile da vedere. In genere si tratta solo di valori, non vengono utilizzati come parte della struttura del programma e quindi il valore che circonda non avrebbe conseguenze disastrose per il programma (anche se potrebbe essere per i dati). Inoltre, i tipi di data e ora in C, C ++ ecc. Sono generalmente definiti più rigorosamente; e quindi le persone che scrivono il programma non devono preoccuparsi che possa cambiare tra le piattaforme.

In un progetto che abbiamo realizzato, abbiamo avuto una situazione in cui il dimensionamento di alcuni database è stato effettuato in un modo che non sarebbe sostenibile dopo 30 anni di utilizzo del software. Quando il cliente chiese al nostro ingegnere capo all'epoca: "Bene, cosa faremo dopo 30 anni di utilizzo del software?" Il nostro ingegnere capo, freddo come un cetriolo, rispose con un'alzata di spalle: "Andremo a bere una birra!"

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