「時間の終わり」の定数はありますか？

一部のシステムでは、時間値9999-12-31が、コンピューターが計算できる時間の終わりとして「時間の終わり」として使用されます。しかし、それが変化したらどうなるでしょうか？今回は組み込み変数として定義する方が良いと思いませんか？

Cおよびその他のプログラミング言語では、通常MAX_INT、整数が持つことのできる最大値を取得するための変数などがあります。MAX_TIME多くのシステムで通常9999-12-31である「時間の終わり」に変数を設定するために、同様の機能がないのはなぜですか。間違った年（9999）にハードコーディングする問題を回避するために、これらのシステムは「時間の終わり」に変数を導入できますか？

**実際の例**

End of validity date: 31/12/9999.（公式文書はこのようにリストされています）ブロガーは、常に一番上にあるページ、ウェルカムページを書きたいと考えています。したがって、可能な限り将来の日付が与えられます。

3000？はい、あなたが直面しているウェルカムページは3000年1月1日に投稿されています。したがって、このページは永久にブログの上部に保持されます=）実際には2007年8月31日に投稿されています。

そもそもなぜこのような変数が必要なのかを自問してください。

ほとんどの場合、あなたは自分のデータについて嘘をついています。「時間の終わり」変数が必要なときはいつでも、実際の時間の終わりを参照していません。むしろ、「この日付に上限はない」、「このイベントは無期限に続く」などのようなことを表現しています。

正しい解決策は、マジック値に依存するのではなく、これらの意図を直接表現することです。null可能な日付タイプ（null「終了日設定なし」を示す）を使用し、「不定」ブールフィールドを追加し、多相ラッパーを使用します実際の日付または特別な「不定」値のいずれか）、またはプログラミング言語が提供するものは何でも。

もちろん、正しい解決策が常に実現可能であるとは限らないため、結局は魔法の値を使用することになりますが、その場合は、日付ごとに適切な値を決定する必要があります。理にかなっているのは、モデリングしているドメインによって異なります-ログのタイムスタンプを保存している場合は、01/01/01が妥当な「時間の終わり」です。あなたのアプリケーションが今からほぼ1000年使用されている可能性は、ほぼゼロだと思います。カレンダーアプリケーションについても同様の考慮事項があります。しかし、もしあなたのソフトウェアが科学データ、例えば地球の気候に関する長期的な予測を処理する場合はどうでしょうか？それらは実際に未来に千年を見たいと思うかもしれない。または、さらに一歩進んでください。天文学、何十億年という非常に長い期間で推論するのが完全に普通の分野、道と未来の両方に。それらの場合、1999年1月1日は完全にばかげた任意の最大値です。OTOHは、10兆年先までのタイムスパンを処理できるカレンダーシステムであり、歯科医の予約追跡システムにとっては、ストレージ容量だけでは実用的ではありません。

言い換えれば、定義が間違っていてarbitrary意的な値を最初から選択することはできません。これが、プログラミング言語で定義されたものを見るのが本当に珍しい理由です。通常は「時間の終わり」という名前ではなく、DATE_MAX（またはDate.MAX）のようなもので、「時間の終わり」ではなく「日付データ型に格納できる最大値」または「無期限」。

業界として、私たちは数バイトを節約するために近視眼的でarbitrary意的であることが有名です。

• 99年12月31日
• 2038年1月19日
• T + 50年。うまくいけば、私が関わったすべてのシステムが機能しなくなったか、交換されました（または、どちらか早いほうで死んでいます）。

私見の最善策は、「最大日付」で適切な主流レベルの抽象化を維持し、時間の到来前に共通の解決策が問題に対処することを期待することです。

たとえば、.NETでは、DateTime.MaxValueは任意23:59:59.9999999, December 31, 9999, exactly one 100-nanosecond tick before 00:00:00, January 1, 10000です。したがって、自分の寿命に関する私の仮定が間違っていて、10000年が到来した場合、フレームワークDateTime.MaxValueの新しいバージョンでのアプリの再コンパイルが新しい任意の値に拡張されることを望んでいます。さらに数千年先の問題をさらに追い詰めます。

編集

（強化期の人たちは、人為的な日付を間違えるのではなく、終了日がないという事実を消費者に明示的に強調する方が正しいと指摘している。）

を使用する代わりにnull、参照型（.Net Nullable`を含む）と互換性があるというマイナスの結果があり、FP言語では、チェックを忘れた消費者にNREの問題を引き起こす可能性があります。返される場合と返されない場合がある値のOptionまたはMaybe Typeラッパー。

擬似コード：

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

これを行うことの利点は、消費者に両方のケースを推論させることです。パターンマッチングもここでは一般的です。

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

おそらくalgebraic data type、無限大のwithバリアントが必要ですdate。次に、比較を定義します。この場合、infiniteバリアントは常に他のものよりも大きくなりますdate。

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

時刻を64ビットIEE754倍精度浮動小数点数として保存し、を使用できます+INF。単精度を使用しないでください。これは7桁の精度であり、日付としては少し低いです。

Cocoa / Objective-Cには、参照している種類を正確に表すファクトリメソッド[NSDate distantPast]および[NSDate distantFuture]があります。

現在の実装によって返される値は、約0 ADおよび4000 ADを表す定数ですが、これらは保証も文書化もされていません。

通常、このような値はありません。言語構成体としては役に立たないからです。

MAX_INTそして、それはすべて目的を果たしている近親者です。コードで使用して、オーバーフローをチェックできます。これは、配列、ベクターなどの大きなデータオブジェクトを作成および管理する場合に便利です。また、プラットフォーム固有の値でもあります。

MAX_DATE値のユースケースは見にくいです。通常、これらは単なる値であり、プログラムの構造の一部として使用されることはありません。そのため、値が循環しても、プログラムに悲惨な結果をもたらすことはありません（データには影響します）。また、C、C ++などの日付と時刻のタイプは通常、より厳密に定義されています。そのため、プログラムを作成する人々は、プラットフォーム間でプログラムが変わる可能性があることを心配する必要はありません。

私たちが行ったプロジェクトの1つでは、データベースのサイズ変更が、ソフトウェアを30年間使用した後では持続不可能な方法で行われました。クライアントが当時のリードエンジニアに尋ねたとき、「それでは、30年間ソフトウェアを使用した後、私たちは何をするつもりですか？」キュウリのようにクールな私たちの主任エンジニアは、肩をすくめて答えました。「ビールを持って行きましょう！」

ポイントは、将来に十分な日付を使用することです。ソフトウェアがそれまでにアップグレードまたは置き換えられる可能性があります。:)