Что мы должны сделать, чтобы подготовиться к 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);
}
результаты выполнения:
- ЧТ 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 PST 1969
- сб 30 августа 12: 02: 40 PDT 2008
- сб 16 августа 23:12: 55 PST 292278994
- ВС дек 02 08: 47: 04 PST 292269055
а как же 292278994 год?
10 ответов:
Я написал портативную замену для времени.h (в настоящее время только localtime(), gmtime(), mktime() и timegm ()), который использует 64-битное время даже на 32-битных машинах. Он предназначен для включения в проекты C в качестве замены времени.ч. Он используется в Perl, и я намерен исправить Руби и 2038 проблемы в Python с ним. Это дает вам безопасный диапазон +/- 292 млн. лет.
код в проекте y2038. Пожалуйста, не стесняйтесь размещать любые вопросы к проблема tracker.
Что касается "это не будет проблемой в течение еще 29 лет", просмотрите это список стандартных ответов для этого. Короче говоря, вещи происходят в будущем, и иногда вам нужно знать, когда. У меня тоже есть презентация по проблеме, что не является решением, а что такое.
О, и не забывайте, что многие системы времени не обрабатывают даты до 1970 года. Все произошло до 1970 года, иногда нужно знать когда.
вы всегда можете реализовать RFC 2550 и быть в безопасности навсегда ; -)
известная вселенная имеет конечное прошлое и будущее. Текущий возраст Вселенная оценивается в [Zebu] как между 10 * * 10 и 2 * 10 ** 10 лет. Смерть Вселенной оценивается в [Найджел], чтобы произойти in 10 ** 11 - лет и в [Дрейк] как происходит либо в 10 * * 12 годы для замкнутой вселенной (большой хруст) или 10 * * 14 лет для открытая вселенная (Тепловая смерть Вселенной).
совместимые с Y10K программы могут ограничить диапазон дат, которые они поддержка тех, кто соответствует ожидаемой жизни Вселенной. Системы y10k уступчивые должны признавать даты Y10K от 10 * * 12 лет внутри прошлое на 10 * * 20 лет в будущее. Совместимые системы Y10K Следует принимать даты не менее 10 * * 29 лет в прошлом и будущее.
Visual Studio перешел к 64-битному представлению time_t в Visual Studio 2005 (при этом все еще оставляя _time32_t для обратной совместимости).
до тех пор, пока вы будете осторожны, чтобы всегда писать код с точки зрения time_t и не предполагать ничего о размере, то как sysrqb указывает, что проблема будет решена вашим компилятором.
Я думаю, что мы должны оставить жучок. Тогда около 2036 года мы можем начать продавать консультации за большие суммы денег, чтобы проверить все. Ведь не так мы успешно справились с опрокидыванием 1999-2000 годов.
Я просто шучу!
Я сидел в банке в Лондоне в 1999 году и был очень удивлен, когда увидел, что консультант начал Y2K тестирование кофе-машины. Я думаю, что если мы что-то и узнали из этого фиаско, то это то, что подавляющее большинство программного обеспечения будет просто работать и большая часть остальных не вызовет расплавления, если он выйдет из строя и может быть исправлен после события, если это необходимо. Таким образом, я не буду принимать никаких особых мер предосторожности до тех пор, пока не приблизится время.
учитывая мой возраст, я думаю, что я должен платить много в свою пенсию и платить за все мои отделы, поэтому кто-то еще должен будет соответствовать программному обеспечению!
Извините, если вы думаете о "чистой приведенной стоимости" любого программного обеспечения, которое вы пишете сегодня, это не влияет на то, что программное обеспечение делает в 2038 году. "Возврат инвестиций" более чем на несколько лет является необычным для любого программного проекта, поэтому вы зарабатываете намного больше денег для своего работодателя, получая программное обеспечение поставляется быстрее, а не думать, что далеко впереди.
единственным распространенным исключением является программное обеспечение, которое должно предсказать будущее, 2038 уже является проблемой для ипотечных котировочных систем.
храните хорошую документацию и включайте описание ваших временных зависимостей. Я не думаю, что многие люди думали о том, насколько трудным может быть этот переход, например, HTTP-куки будут сломаны в эту дату.
что мы должны сделать, чтобы подготовиться к 2038?
скрыть, потому что апокалипсис грядет.
но серьезно, я надеюсь, что компиляторы (или люди, которые их пишут, если быть точным) могут справиться с этим. У них почти 30 лет. Надеюсь, этого времени хватит.
в какой момент мы начинаем подготовку к Y10K? Есть ли какие-либо производители оборудования / исследовательские лаборатории изучили самый простой способ перейти к любой новой технологии, которую мы должны будем иметь из-за этого?
Я работаю в embedded, и я думал, что опубликую наше решение здесь. Наши системы находятся на 32 битах, и то, что мы продаем прямо сейчас, имеет гарантию 30 лет, что означает, что они столкнутся с ошибкой 2038 года. Модернизация в будущем не была решением.
чтобы исправить это, мы установили дату ядра на 28 лет раньше текущей даты. Это не случайное смещение, 28 лет-это время, которое потребуется для дней недели, чтобы снова совпасть. Например, я пишу на в четверг и в следующий раз 7 марта будет четверг-в 28 лет.
кроме того, все приложения, которые взаимодействуют с датами в наших системах, возьмут системную дату (time_t), преобразуют ее в пользовательский time64_t и применяют смещение 28 лет к правильной дате.
мы сделали пользовательскую библиотеку, чтобы справиться с этим. Код, который мы используем, основан на этом:https://github.com/android/platform_bionic
таким образом, с этим решением вы можете купить себя дополнительные 28 лет легко.