Есть ли константа для «конца времени»?

Для некоторых систем значение времени 9999-12-31 используется как «конец времени» как конец времени, которое может вычислить компьютер. Но что, если это изменится? Не лучше ли определить это время как встроенную переменную?

В C и других языках программирования обычно существует переменная типа MAX_INTили подобная, чтобы получить наибольшее значение, которое может иметь целое число. Почему нет аналогичной функции для MAX_TIMEie установить переменную на «конец времени», который для многих систем обычно равен 9999-12-31. Чтобы избежать проблемы жесткого кодирования в неправильный год (9999), могут ли эти системы ввести переменную для «конца времени»?

** реальный пример **

End of validity date: 31/12/9999.(официальные документы перечислены так). Блоггер хочет написать страницу, которая всегда находится сверху, страницу приветствия. Таким образом, ему дана дата как можно дальше в будущем:

3000? Да, страница приветствия, с которой вы сталкиваетесь, размещена 1 января 3000 года. Так что эта страница всегда будет оставаться в верхней части блога =) На самом деле она размещена 31 августа 2007 года.

Спросите себя, зачем вам такая переменная в первую очередь.

Скорее всего, вы лжете о своих данных: всякий раз, когда вам нужна переменная «конец времени», вы не ссылаетесь на фактический конец времени; скорее вы выражаете такие вещи, как «нет верхней границы для этой даты», «это событие продолжается бесконечно» или подобное.

Таким образом, правильное решение состоит в том, чтобы выразить эти намерения напрямую, вместо того, чтобы полагаться на магическое значение: использовать типы дат, допускающие значение NULL (где nullуказано «не задано конечное значение даты»), добавить «неопределенное» логическое поле, использовать полиморфную оболочку (которая может будь то реальная дата или специальное «неопределенное» значение), или то, что может предложить ваш язык программирования.

Конечно, правильное решение не всегда выполнимо, поэтому вы можете в конце концов использовать магическое значение, но когда вы это сделаете, вы должны выбрать подходящее значение для каждого конкретного случая, потому что какие даты делают и не делают смысл имеет смысл в зависимости от домена, который вы моделируете - если вы храните временные метки журнала, 01.01.2999 является разумным «концом времени»; я полагаю, что шансы на то, что ваше приложение будет использоваться почти 1000 лет назад, практически равны нулю. Аналогичные соображения относятся к календарным приложениям. Но что, если ваша программа предназначена для обработки научных данных, скажем, долгосрочных прогнозов о климате Земли? Те, кто может захотеть заглянуть в будущее на тысячу лет. Или сделайте еще один шаг вперед; астрономия, область, где вполне разумно рассуждать в очень больших временных интервалах порядка миллиардов лет, и в путь и в будущее. Для тех 01.01.2999 - совершенно нелепый произвольный максимум. OTOH, календарная система, способная обрабатывать временные промежутки в десять триллионов лет в будущем, вряд ли практична для системы отслеживания назначений стоматолога, хотя бы из-за емкости хранилища.

Другими словами, не существует единственного лучшего выбора для значения, которое является неправильным и произвольным по определению для начала. Вот почему на самом деле редко можно встретить определенное в любом языке программирования; те, которые обычно не называют его «концом времени», а скорее что-то вроде DATE_MAX(или Date.MAX), и принимают его как «наибольшее значение, которое может быть сохранено в типе данных даты», а не «конец времени» или « на неопределенный срок».

Как индустрия мы были заведомо близоруки и произвольны в стремлении сэкономить несколько байтов, например

• 31 декабря 99
• 19 января 2038 г.
• 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(например, путем изменения его базового типа) до нового произвольного значения и продвинуть проблему дальше в течение еще нескольких тысячелетий.

редактировать

(Подчеркивая точку зрения tdammers, что вместо того, чтобы выдумывать искусственную дату, правильнее было бы явно подчеркнуть тот факт, что у нас нет конечной даты.)

В качестве альтернативы использованию null, которое имеет отрицательное следствие совместимости типа с любым ссылочным типом (включая .Net Nullable`), что, вероятно, вызовет проблемы NRE у потребителей, которые забывают проверить, что в языках FP использование банального языка является обычным явлением. Option или Maybe Введите обертку вокруг значения, которое может или не может быть возвращено.

Псевдокод:

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вариант с бесконечно большим 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 ++ и т. Д. Обычно определены более строго; и поэтому люди, пишущие программу, не должны беспокоиться о том, что она может меняться между платформами.

В одном проекте, который мы реализовали, у нас была ситуация, когда изменение размеров базы данных было выполнено таким образом, который не был бы устойчивым после 30 лет использования программного обеспечения. Когда клиент спросил нашего ведущего инженера: «Что мы будем делать после 30 лет использования вашего программного обеспечения?» Наш ведущий инженер, крутой как огурец, пожал плечами: «Пойдем и выпьем пива!»

Дело в том, просто используйте дату, которая достаточно далеко в будущем. Скорее всего, ваше программное обеспечение будет обновлено или заменено к тому времени. :)