Чи є константа для "кінця часу"?

Для деяких систем значення часу 9999-12-31 використовується як "кінець часу", як кінець часу, який комп'ютер може обчислити. Але що робити, якщо це зміниться? Чи не було б краще визначити цей час як вбудовану змінну?

У C та інших мовах програмування зазвичай є така змінна, як MAX_INTабо подібні, щоб отримати найбільше значення, яке може мати ціле число. Чому не існує подібної функції для MAX_TIMEтобто встановити змінну на "кінець часу", яка для багатьох систем зазвичай дорівнює 9999-12-31. Щоб уникнути проблеми жорсткого кодування до неправильного року (9999), чи могли б ці системи ввести змінну на "кінець часу"?

** Реальний приклад **

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

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

Запитайте себе, навіщо вам потрібна така змінна.

Швидше за все, ви брешите про свої дані: коли вам потрібна змінна "кінець часу", ви не маєте на увазі фактичного кінця часу; скоріше ви висловлюєте речі типу "немає верхньої межі для цієї дати", "ця подія триває нескінченно" або подібне.

Правильне рішення, таким чином, полягає в тому, щоб висловити ці наміри безпосередньо, а не покладатися на магічне значення: використовуйте зведені типи дат (де 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(наприклад, змінивши його базовий тип) на нове довільне значення і підштовхнути проблему далі вниз ще на кілька тисячоліть.

Редагувати

(Підсилюючи темпаммері, що замість того, щоб підробляти штучну дату, правильніше явно виділити споживачеві той факт, що у нас немає кінцевої дати.)

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

Псевдокод:

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 цифр, що трохи знижує дату.

Какао / Objective-C має заводські методи [NSDate remotePast] та [NSDate remoteFuture], які точно представляють те, про що йдеться.

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

Зазвичай це не таке значення, оскільки воно не було б корисним як мовна конструкція.

MAX_INTі це споріднення служить цілі. Вони можуть використовуватися у вашому коді для перевірки проти переповнення. Це корисно, якщо ви збираєтесь створювати та керувати великими об’єктами даних у масивах, векторах і будь-якому іншому. Це також досить орієнтоване на платформу значення.

Випадок використання MAX_DATEзначення важче зрозуміти. Зазвичай це просто значення, вони не використовуються як частина структури програми, і тому значення, яке кружляє навколо, не мало б шкідливих наслідків для програми (хоча це може бути і для даних). Також типи дати та часу в C, C ++ тощо, як правило, більш чітко визначені; і тому люди, які пишуть програму, не повинні хвилюватися, що вона може змінюватися між платформами.

В одному з проектів, які ми зробили, у нас виникла ситуація, коли розмір деякої бази даних робився таким чином, що не було б стійким після 30 років використання програмного забезпечення. Коли клієнт в той час запитав нашого провідного інженера: "Ну, що ми будемо робити після 30 років використання вашого програмного забезпечення?" Наш провідний інженер, крутий, як огірок, відповів плечима: "Ми підемо пити!"

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