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

12

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

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

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

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

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

Никлас
источник
6
Почему? Это похоже на проблему, которая может быть решена путем реализации правильного алгоритма или структуры данных.
Эйфорическая
16
Я думаю, что большинство людей пока не очень беспокоятся о проблеме Y10K :-) Тем более, что до этого у нас обязательно будет проблема Y2038 , и, вероятно, еще пара ...
Péter Török
2
@ Thorbjörn, да, вероятно, большинство живых систем будут перенесены к тому времени. Тем не менее, в настоящее время все еще может существовать неоценимое количество старых встроенных систем, устаревших баз данных, файлов в устаревших форматах и ​​т. Д.
Péter Török
14
Я думаю, что у календаря майя есть константа "конца времени" = 2012-12-21 ;-)
nikie
3
Никто не знает, когда наступит «конец времени».
Тулаинс Кордова

Ответы:

47

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

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

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

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

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

tdammers
источник
20
использование null для обозначения специального значения на самом деле не лучше, чем использование этого специального значения
Ryathal
2
@Ryathal Ну, я думаю, что нет ошибки 'nullenium', так что, по крайней мере, немного лучше ...
K.Steff
8
@Ryathal: на самом деле это не так. Есть много действий, которые вы можете выполнить с магическим числом, которое вы не можете выполнить с нулем.
Питер Б
21
@Ryathal - nullв этом случае не используется как специальное значение, оно используется как правильное значение null, которое «отсутствует». Так что, если ваше поле ExpiryDate, что является более правильным: null(имеется в виду отсутствие даты истечения срока действия) или END_OF_TIME(который, насколько мы знаем, не существует). Ясно, nullили NoValueчто-то подобное - лучшее решение.
Скотт Уитлок
3
@jwenting - Они не делают различий, потому что нет ни одного. NULL означает, что он не существует, или в более человеческих терминах значение просто не определено.
Ramhound
17

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

  • 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"
}
StuartLC
источник
Duh. Я слепой. Ничего.
ot--
Возможно, когда-нибудь. У нас будет Уильям Кахан для дат и времени. У нас будут такие вещи, как положительные и отрицательные метки времени, NaT«значения» и т. Д.
Росс Паттерсон
4
Не могу не напомнить об этом: exit109.com/~ghealton/y2k/y2k_humor/Cobol.html
Джулия Хейворд,
7

Вы, вероятно, хотите 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

Показать имя
источник
Укажите код в своем ответе для потомков.
Смертельно
2

Сохраняйте время как 64-битное число с плавающей точкой двойной точности IEE754, и вы можете использовать его +INF. Не используйте одинарную точность, это только с точностью до 7 цифр, что немного мало для даты.

MSalters
источник
1

Cocoa / Objective-C имеет фабричные методы [NSDate distantPast] и [NSDate distantFuture], которые представляют собой именно то, на что вы ссылаетесь.

Значения, возвращаемые текущей реализацией, являются константами, представляющими около 0 AD и 4000 AD, хотя они не гарантированы и не задокументированы.

grahamparks
источник
0

Обычно такого значения нет, потому что оно не будет полезным в качестве языковой конструкции.

MAX_INTи это все родственники служат цели. Они могут быть использованы в вашем коде для проверки на переполнение. Это полезно, если вы собираетесь создавать большие объекты данных и управлять ими в массивах, векторах и т. Д. Это также довольно специфичное для платформы значение.

Вариант использования для MAX_DATEзначения сложнее увидеть. Как правило, это просто значения, они не используются как часть структуры программы, и поэтому значение, оборачиваемое вокруг, не будет иметь катастрофических последствий для программы (хотя может и для данных). Кроме того, типы даты и времени в C, C ++ и т. Д. Обычно определены более строго; и поэтому люди, пишущие программу, не должны беспокоиться о том, что она может меняться между платформами.

TZHX
источник
0

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

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

Владимир Стокич
источник