Подтвердить что ты не робот

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

Мне хотелось бы думать, что часть программного обеспечения, которое я пишу сегодня, будет использоваться через 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);
}

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

  • Thu Jan 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 г., см. время (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));
    }
}
  • Wed Dec 31 16:00:00 PST 1969
  • Сб Авг 30 12:02:40 PDT 2008
  • Сб Авг 16 23:12:55 PST 292278994
  • Sun Dec 02 08:47:04 PST 292269055

Но как насчет года 292278994?

4b9b3361

Ответ 1

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

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

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

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

Ответ 2

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

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

 

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

Ответ 4

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

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

Ответ 5

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

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

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

Ответ 6

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

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

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

Ответ 7

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

Ответ 8

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

Скрыть, потому что приближается апокалипсис.

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

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

Ответ 9

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

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

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

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

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

Ответ 10

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

Программы COBOL могут быть интересными, хотя.

Ответ 11

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

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