Y a-t-il une constante pour la «fin des temps»?

Pour certains systèmes, la valeur de temps 9999-12-31 est utilisée comme "fin de temps" comme fin de temps que l'ordinateur peut calculer. Et si ça change? Ne serait-il pas préférable de définir cette fois comme une variable intégrée?

En C et dans d'autres langages de programmation, il existe généralement une variable telle que MAX_INTou similaire pour obtenir la plus grande valeur qu'un entier puisse avoir. Pourquoi n'y a-t-il pas une fonction similaire pour, par MAX_TIMEexemple, définir la variable à la "fin du temps" qui, pour de nombreux systèmes, est généralement 9999-12-31. Pour éviter le problème du codage en dur sur une mauvaise année (9999), ces systèmes pourraient-ils introduire une variable pour la "fin des temps"?

** Exemple réel **

End of validity date: 31/12/9999.(les documents officiels sont listés comme ça) Le blogueur veut écrire une page qui est toujours en haut, la page d'accueil. On lui donne donc une date aussi loin que possible dans le futur:

3000? Oui, la page d'accueil à laquelle vous êtes confronté est postée au 1er janvier 3000. Cette page sera donc conservée en haut du blog pour toujours =) Elle est effectivement postée au 31 août 2007.

Demandez-vous pourquoi vous avez besoin d'une telle variable en premier lieu.

Vous mentez très probablement sur vos données: chaque fois que vous avez besoin d'une variable de «fin de temps», vous ne faites pas référence à la fin de temps réelle; vous exprimez plutôt des choses comme "il n'y a pas de limite supérieure pour cette date", "cet événement continue indéfiniment", ou similaire.

La bonne solution consiste alors à exprimer ces intentions directement au lieu de s'appuyer sur une valeur magique: utilisez des types de date nullables (où nullindique "pas de date de fin définie"), ajoutez un champ booléen "indéfini", utilisez un wrapper polymorphe (qui peut être une date réelle ou une valeur spéciale "indéfinie"), ou tout ce que votre langage de programmation a à offrir.

Bien sûr, la bonne solution n'est pas toujours faisable, vous pouvez donc finir par utiliser une valeur magique, mais lorsque vous le faites, vous devez décider d'une valeur appropriée au cas par cas, car quelles dates le font et ne le font pas. le sens dépend du domaine que vous modélisez - si vous stockez des horodatages de journal, le 01/01/2999 est une "fin de temps" raisonnable; les chances que votre application soit encore utilisée dans près de 1 000 ans sont, je pense, pratiquement nulles. Des considérations similaires s'appliquent aux applications de calendrier. Mais que se passe-t-il si votre logiciel doit gérer des données scientifiques, disons, des prévisions à long terme sur le climat de la Terre? Ceux-ci pourraient en fait vouloir regarder mille ans dans le futur. Ou allez plus loin; l'astronomie, un domaine où il est parfaitement normal de raisonner sur de très grandes périodes de l'ordre de milliards d'années, à la fois dans le chemin et l'avenir. Pour ceux-là, le 01/01/2999 est un maximum arbitraire parfaitement ridicule. OTOH, un système de calendrier capable de gérer des périodes de dix mille milliards d'années dans le futur, n'est guère pratique pour un système de suivi des rendez-vous chez le dentiste, ne serait-ce qu'en raison de la capacité de stockage.

En d'autres termes, il n'y a pas de meilleur choix pour une valeur incorrecte et arbitraire par définition. C'est pourquoi il est vraiment rare d'en voir un défini dans n'importe quel langage de programmation; ceux qui ne le nomment généralement pas "fin du temps", mais plutôt quelque chose comme DATE_MAX(ou Date.MAX), et le prennent pour signifier "la plus grande valeur qui peut être stockée dans le type de données date", pas "la fin du temps" ou "indéfiniment".

En tant qu'industrie, nous avons été notoirement myopes et arbitraires dans la poursuite de la sauvegarde de quelques octets, par exemple

• 31 déc 99
• 19 janvier 2038
• T + 50 ans, quand j'espère que tous les systèmes dans lesquels j'ai été impliqués sont devenus obsolètes ou remplacés (ou je suis mort, selon la première éventualité).

À mon humble avis, le meilleur pari est de maintenir un niveau d'abstraction approprié et général à la «date maximale» et d'espérer qu'une solution commune aura résolu le problème avant l'heure.

par exemple dans .NET, DateTime.MaxValue est arbitrairement 23:59:59.9999999, December 31, 9999, exactly one 100-nanosecond tick before 00:00:00, January 1, 10000. Donc, si mes hypothèses sur ma propre longévité sont fausses et que l'année 10000 arrive, j'espère plutôt qu'une recompilation de mon application avec une version ultérieure du cadre s'étendra DateTime.MaxValue(par exemple en changeant son type sous-jacent) à une nouvelle valeur arbitraire et lancer le problème plus loin sur la route pendant quelques millénaires.

Éditer

(Renforcer le point des tdammers que plutôt que de truquer une date artificielle, qu'il est plus correct de souligner explicitement au consommateur que nous n'avons pas de date de fin.)

Comme alternative à l'utilisation null, qui a pour conséquence négative d'être compatible avec tout type de référence (y compris .Net Nullable`), ce qui entraînera probablement des problèmes de NRE chez les consommateurs qui oublient de vérifier, dans les langages FP, il est courant d'utiliser un Option ou peut-être Tapez un wrapper autour d'une valeur qui peut ou non être renvoyée.

Pseudo code:

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

L'avantage de cette opération est qu'elle oblige le consommateur à raisonner dans les deux cas. La correspondance de motifs est également courante ici:

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

Vous voulez probablement une algebraic data typevariante avec pour un grand infini date. Définissez ensuite la comparaison, dans laquelle la infinitevariante sera toujours plus grande que toute autre date.

Exemple à 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

Stockez vos heures sous forme de nombre à virgule flottante double précision IEE754 64 bits, et vous pouvez l'utiliser +INF. N'utilisez pas la simple précision, qui n'est précise qu'à 7 chiffres, ce qui est un peu faible pour une date.

Cocoa / Objective-C a des méthodes d'usine [NSDate distantPast] et [NSDate distantFuture] qui représentent exactement le genre de chose dont vous parlez.

Les valeurs renvoyées par l'implémentation actuelle sont des constantes représentant environ 0 AD et 4000 AD, bien qu'elles ne soient ni garanties ni documentées.

Il n'y a généralement pas une telle valeur, car elle ne serait pas utile comme construction de langage.

MAX_INTet ses parents servent tous un but. Ils peuvent être utilisés dans votre code pour vérifier les débordements. C'est utile si vous allez créer et gérer de gros objets de données dans des tableaux, des vecteurs, peu importe. C'est également une valeur assez spécifique à la plate-forme.

Le cas d'utilisation d'une MAX_DATEvaleur est plus difficile à voir. En général, ce ne sont que des valeurs, elles ne sont pas utilisées dans le cadre de la structure du programme, et donc la valeur qui tourne autour n'aurait pas de conséquences désastreuses pour le programme (même si cela peut affecter les données). De plus, les types de date et d'heure en C, C ++, etc. sont généralement définis de manière plus stricte; et donc les personnes qui écrivent le programme n'ont pas à craindre qu'il puisse changer entre les plates-formes.

Sur un projet que nous avons fait, nous avons eu une situation où le dimensionnement d'une base de données a été fait d'une manière qui ne serait pas durable après 30 ans d'utilisation du logiciel. Lorsque le client a demandé à notre ingénieur en chef à l'époque: "Eh bien, qu'allons-nous faire après 30 ans d'utilisation de votre logiciel?" Notre ingénieur en chef, cool comme un concombre, a répondu avec un haussement d'épaules: "Nous irons prendre une bière!"

Le fait est qu'il suffit d'utiliser la date qui est suffisamment éloignée à l'avenir. Il y a de fortes chances que votre logiciel soit mis à niveau ou remplacé d'ici là. :)