-
-
B23 ноя 15А что мешает провести эксперимент и на своём домашнем ПК установить дату — 03:14:00, вторник, 19 января 2038 года и через 7 секунд убедиться в надуманности проблемы? Или для этого надо университеты заканчивать, гранды получать, обладать учёными званиями?
Такую же проблему описывали в момент смены с 1999 года на 2000 год. Итог — нервные и доверчивые свои старые компьютеры повыбрасывали, закупив новые и обогатив производителей компьютерной техники. Новое — хорошо забытое старое. Особенно если это касается развода лохов... -
23 ноя 15Ага. Помнится эпидемия страданий по проблеме 2000...
Новоявленные нострадамусы тогда тоже вовсю пылили поносными предсказаниями. Наконец, искомая новогодняя ночь расставила все по своим местам. Так нашлись и те, которые "перенесли" проблему на 2001 год, но снова ничего не произошло.
И вот опять. -
23 ноя 15Моему компу 10 лет и менять его не собираюсь. Но в 38 видимо придется. -
M23 ноя 15Это не проблема, будут считать с нуля снова как дельту, прибавляемую к этой дате — к тому времени во все программы можно ввести коррекцию, даже оставаясь на 32 битной системе.
Я в свои приборы упаковываю год, месяц, число и АБСОЛЮТНОЕ время до секунд всего в четыре байта, мне их хватит до 2064 года. после этого, базовый софт понимая что есть такая огромная рассинхронизация элементарно начинает считать методом прибавления моих данных к 2064 году.
Делается просто, в основной программе искусственно ставится в единицу тридцать третий бит счетчика.-
23 ноя 15Дешевый планшет Digma (Android без синхронизации времени через gsm/wifi) после перехода через 3:14:07 19.01.2038 ушел в глухой зависон, Power — не отвечает, только хард ресет скрепкой.
В Win8.1(x32) максимум в командной строке получилось 22:49 5.12.8907(GMT+4), винда стала требовать активацию и жаловаться ,что долго не ставил обновления.
А, а сайт iCloud.com стал показывать "Copyright (c) 8907 Apple Inc. Все права защищены"
Это они для путешествий во времени, наверное... ;)-
M23 ноя 15Все сегодняшние планшеты в 2038 году можно будет найти разве что в музеях :-)
К тому времени к этой проблеме подготовятся.
Вон перед 2000 годом тоже стращали, и ничего, вроде все в порядке.
-
-
-
23 ноя 15Через 20 лет придумают 128-ую систему и проблема уйдёт сама собой... -
R23 ноя 15да успокойтесь, а с 8-16 битными системами, не так было?
а проблема 2000-го года?
ну перестанут пахать ваши раритетные часы или кофемолка )) подумаешь, покупайте новые, старые девайсы на помойку или в музей ))
компы программно это обходят, а к 2038 году все 32-х битные компы просто морально устареют -
23 ноя 152038?? к тому времени выпустят обновление операционок, а ныне действующий аппаратный парк уже и на помойках перестанет встречаться, возможно будут образцы в захолустных музеях. -
H23 ноя 15Проблема Y2K была вполне реальна, поскольку на тот момент в работе было полно систем, использующих 2 цифры для хранения года (оно и понятно, тогда экономили не то что каждый байт, а каждый бит).
Системы, понятно дело, не десктопные, поэтому большинство пользователей этого не заметили никак вообще. Но тем не менее там реально надо было переписывать код, причем код весьма старый, поэтому ООПшная школота со своими фреймворками на все случаи жизни, пролетала в таких работах как фанера над парижем. Программерам на коболе, по слухам, тогда были готовы платить неплохие бабки.
С unixtime'ом проблема больше высосана из пальца, поскольку как и в статье заметили, используется тип time_t, и если кодер не мудак (т.е. не определил переменную как int), все что надо — это перекомпилировать софт с новым time.h.
Специально проверил: sizeof(time_t) под ubuntu 12.04 i686 равен 4 байтам, под FC 22 x64 — 8 байт.
проблем с несовместимостью этих систем я пока не наблюдаю.
конечно, если сделать на одной write( f , time , sizeof(time_t)) а на другой read(f,&time,sizeof(time_t)) то проблемы будут, но это проблемы быдлокодера, а не unixtime, никто не гарантировал конкретную размерность тех или иных данных на любой архитектуре, что известно любому Си-шному программеру. Хочешь конкретных байт — используй intN_t/uintN_t.
Я как-то давно наступил на эти грабли, сделал структуру, описывающую заголовок bmp файла, считываю — явно какая-то лажа. Внезапно выяснилось, что компилятор для оптимизации произвел выравнивание данных на размер слова, т.е. 32 бита. :)
Вообщем-то даже на 32-битных системах ничего не мешает определить time_t как int64_t и просто перекомпилировать. Разве что код потом не влезет в какой-нибудь микроконтроллер, где все оптимизированно с точностью до байта.
ps. Лучше бы вспомнили более насущные проблемы — IPv4/IPv6, и то, что много оборудования до сих пор не поддерживает бесклассовые IP-сети. В ZyXEL'овской точке доступа/роутере на LAN-интерфейсе можно поставить только /24 и никак иначе. Поэтому в сети /22 не с любого компа можно зайти на ее интерфейс. :)
Сделано с
NoNaMe