Что мы должны сделать, чтобы подготовиться к 2038 году?

Question

Я хотел бы думать, что часть программного обеспечения, которое я пишу сегодня, будет использоваться через 30 лет. Но я также знаю, что многое из этого основано на традиции UNIX, которая показывает время как число секунд с 1970 года.

#include <stdio.h>
#include <time.h>
#include <limits.h>

void print(time_t rt) {
    struct tm * t = gmtime(&rt);
    puts(asctime(t));
}

int main() {
    print(0);
    print(time(0));
    print(LONG_MAX);
    print(LONG_MAX+1);
}

Результаты выполнения в:

• Чт 1 января 00:00:00 1970
• Сб 30 августа 18:37:08 2008
• Вт 19 января 03:14:07 2038
• Пт. 13 декабря 20:45:52 1901

Функции ctime (), gmtime () и localtime () все принимают в качестве аргумента значение времени, представляющее время в секундах с начала эпохи (00:00:00 UTC, 1 января 1970 года; см. Time (3) )).

Интересно, есть ли какие-либо активные действия в этой области в качестве программиста, или мы должны верить, что все программные системы (операционные системы) каким-то образом будут магически обновлены в будущем?

Обновление Казалось бы, действительно 64-битные системы защищены от этого:

import java.util.*;

class TimeTest {
    public static void main(String[] args) {
        print(0);
        print(System.currentTimeMillis());
        print(Long.MAX_VALUE);
        print(Long.MAX_VALUE + 1);
    }

    static void print(long l) {
        System.out.println(new Date(l));
    }
}

• ср. 31 декабря 16:00:00 по тихоокеанскому времени 1969
• Сб 30 августа 12:02:40 PDT 2008
• Сб 16 августа 23:12:55 PST 292278994
• Вс. 02 дек. 08:47:04 PST 292269055

А как насчет 292278994?

Answer 1

Я написал переносимую замену для time.h (в настоящее время это только localtime (), gmtime (), mktime () и timegm ()), который использует 64-битное время даже на 32-битных машинах. Он предназначен для использования в проектах C в качестве замены для time.h. Он используется в Perl, и я собираюсь исправить с ним проблемы с Ruby и Python 2038 года. Это дает вам безопасный диапазон +/- 292 миллиона лет.

Код можно найти в проекте y2038 . Пожалуйста, не стесняйтесь задавать любые вопросы на трекер .

Что касается того, что «это не будет проблемой в течение следующих 29 лет», просмотрите этот список стандартных ответов на это. Короче говоря, вещи случаются в будущем, и иногда вам нужно знать, когда. У меня также есть презентация по проблеме, что не является решением, а что такое .

О, и не забывайте, что многие системы времени не обрабатывают даты до 1970 года. Все происходило до 1970 года, иногда вам нужно знать, когда.

Answer 2

Вы всегда можете реализовать RFC 2550 и быть в безопасности навсегда; -)

Известная вселенная имеет конечное прошлое и будущее. Текущий возраст Вселенная оценивается в [Зебу] как между 10 ** 10 и 2 * 10 ** 10 лет. Смерть вселенной в Найджеле, по оценкам, произойдет через 10 ** 11 - лет и в [Drake], как происходит либо в 10 ** 12 лет для закрытой вселенной (большой кризис) или 10 ** 14 лет для открытая вселенная (тепловая смерть вселенной).

Программы, совместимые с Y10K, МОГУТ ограничить диапазон дат, которые они поддержка тех, кто соответствует ожидаемой жизни вселенной. Системы, соответствующие Y10K, ДОЛЖНЫ принимать даты Y10K от 10 ** до 12 лет Прошлое 10 ** 20 лет в будущее. Y10K-совместимые системы ДОЛЖНЫ принимать даты как минимум 10 ** 29 лет в прошлом и будущее.

Answer 3

Visual Studio перешел на 64-битное представление time_t в Visual Studio 2005 (при этом все еще остается _time32_t для обратной совместимости).

Пока вы стараетесь всегда писать код в терминах time_t и не предполагаете ничего о размере, тогда, как указывает sysrqb, проблема будет решена вашим компилятором.

Answer 4

Я думаю, что мы должны оставить ошибку. Затем, около 2036 года, мы можем начать продавать консультационные услуги за большие суммы денег, чтобы проверить все. В конце концов, это не то, как мы успешно справились с опрокидыванием 1999-2000 годов.

Я только шучу!

Я сидел в банке в Лондоне в 1999 году и был очень удивлен, когда увидел, как консультант начал тестирование кофеварки Y2K. Я думаю, что если мы узнали что-то из этого фиаско, то это было то, что подавляющее большинство программного обеспечения будет просто работать, а большая часть остального не вызовет сбой в работе, если он выйдет из строя и может быть исправлен после события, если это необходимо. Поэтому я бы не стал предпринимать никаких особых мер предосторожности, пока не приблизился бы ко времени.

Answer 5

Учитывая мой возраст, я думаю, что я должен много заплатить в свою пенсию и заплатить все свои взносы, так что кто-то другой должен будет соответствовать программному обеспечению!

Извините, если вы думаете о «чистой приведенной стоимости» любого программного обеспечения, которое вы пишете сегодня, оно не влияет на то, что программное обеспечение делает в 2038 году. «Возврат инвестиций», превышающий несколько лет, является редкостью для любого программного обеспечения. проект, так что вы зарабатываете гораздо больше денег для своего работодателя, поставляя программное обеспечение быстрее, а не думая, что далеко вперед.

Единственным распространенным исключением является программное обеспечение, которое должно предсказывать будущее, 2038 уже является проблемой для систем ипотечных котировок.

Answer 6

Я работаю во встроенном, и я думал, что выложу наше решение здесь. Наши системы работают на 32 битах, и то, что мы продаем сейчас, имеет гарантию 30 лет, что означает, что они столкнутся с ошибкой 2038 года. Обновление в будущем не было решением.

Чтобы исправить это, мы устанавливаем дату ядра на 28 лет раньше текущей даты. Это не случайное смещение, 28 лет - это то же самое время, что и дни недели, чтобы снова соответствовать. Например, я пишу это в четверг, и в следующий раз 7 марта будет четверг через 28 лет.

Кроме того, все приложения, которые взаимодействуют с датами в наших системах, возьмут системную дату (time_t), преобразуют ее в пользовательский time64_t и применят смещение 28 лет к правильной дате.

Мы создали специальную библиотеку для этого. Код, который мы используем, основан на этом: https://github.com/android/platform_bionic

Таким образом, с этим решением вы можете легко купить себе дополнительные 28 лет.

Answer 7

Что мы должны сделать, чтобы подготовиться к 2038 году?

Спрячься, потому что грядет апокалипсис.

А если серьезно, я надеюсь, что компиляторы (или люди, которые их пишут, если быть точным) справятся с этим. У них есть почти 30 лет. Надеюсь, хватит времени.

В какой момент мы начинаем готовиться к Y10K? Обсуждали ли производители оборудования / исследовательские лаборатории самый простой способ перейти на любую новую технологию, которая у нас будет из-за этого?

Answer 8

Храните хорошую документацию и включайте описание ваших временных зависимостей. Я не думаю, что многие люди думали о том, насколько сложным может быть этот переход, например, в этот день файлы cookie HTTP будут ломаться.

Answer 9

Оперативное слово «должен».

Если вам нужно обеспечить защиту будущего, вы можете создать свой собственный класс даты / времени и использовать его, но я сделаю это только в том случае, если вы считаете, что написанное вами будет использоваться в устаревшей ОС '

Answer 10

К 2038 году все временные библиотеки должны использовать 64-разрядные целые числа, так что на самом деле это не будет большой проблемой (для программного обеспечения, которое не полностью не поддерживается).

Программы на COBOL могут быть забавными.