Натолкнулся на эти грабли при переводе старого проекта на MSVS2005
Я все понимаю, проблема 2038 года, и все такое, но до нее еще 30 лет !!!
Сейчас еще полно кода, для которого 64битные time_t это откровение, так спрашивается какого фига так делать по дефолту?
И ATL CTime переписали... блин
ЗЫ
Кто как решил для себя решать проблему 2038 года?
ЗЫЗЫ
Я смотрю народ активно уже стал домены занимать
Здравствуйте, BishopMorton, Вы писали:
BM>Я все понимаю, проблема 2038 года, и все такое, но до нее еще 30 лет !!!
Уже всего 20. Пора бы начать думать.
PS: последствие Y2k38 я уже видел — у человека в банке неправильно рассчитывался кредит на 20 лет
Патамушта микрасофт !
> Натолкнулся на эти грабли при переводе старого проекта на MSVS2005
Гы ... и ты тоже ...
USE_32BIT_TIME_T тебе в помощь...
MySQL кстати только из-за этого на 2005 студии не компилится.
> Кто как решил для себя решать проблему 2038 года?
AleksandrN пишет: > Вроде-бы, разрядность time_t всегда равна разрядности системы (и в > Windows и в UNIX).
1) Разрядность системы — 32 бита. Т.е. это — WinXP 32. time_t при этом — 64
2) Все старые приложения тоже так думали, и писали соответственно
time_t tval;
sometime_func ( (int) tval );
Оно понятно, что неправильно, но что ж делать -то ...
Здравствуйте, Michael7, Вы писали:
M>Здравствуйте, Cyberax, Вы писали:
BM>>>Я все понимаю, проблема 2038 года, и все такое, но до нее еще 30 лет !!! C>>Уже всего 20. Пора бы начать думать.
M>2038-2008=30
Ученые Главной (Пулковской) обсерватории РАН не исключают возможность столкновения астероида с Землей в 2035 году, однако точнее определить вероятность возникновения катастрофы смогут лишь в 2028 году.
2Cyberax
В целом проблема, конечно, важная, но у редких продуктов срок саппорта больше 30 лет... Могли бы в MS уж при конвертации старого кода какую-нибудь макруху взводить, чтобы не использовались 64битные числа для хранения веремени, ну и ворнинг соответствующий. Из-за этого неявного перехода очень много багов может появится и без 2038 года
Здравствуйте, pvirk, Вы писали:
P>Здравствуйте, BishopMorton, Вы писали:
BM>>Кто как решил для себя решать проблему 2038 года?
P>boost::date_time и никаких проблем.
Здравствуйте, BishopMorton, Вы писали:
P>>boost::date_time и никаких проблем.
BM>А с какой версией нет проблем?
BM>http://www.boost.org/doc/html/date_time/gregorian.html#date_construct_from_clock BM>Internally boost::gregorian::date is stored as a 32 bit integer type.
BM>У меня только boost_1_31_0 завалялся, дык там вызовы localtime... и тп BM>ничего 64 битного для времени не нашел...
Вот же из документации
The current implementation supports dates in the range 1400-Jan-01 to 9999-Dec-31
Конструктор типа boost::gregorian::date(9999,1,1) работает правильно.
Если надо получить секунды от 1970 года — заполняем tm нужными данными, юзаем boost::posix_time::ptime_from_tm(tm&) и отнимаем от него boost::gregorian::date(1970,1,1) — получаем boost::posix_time::time_duration td — в нём часы, минуты и секунды от 1.1.1970.
Если надо перевести секунды в дату > 2300года, то примерно так
long long secs = 1000000000000;
long long hours = secs/3600;
date d = ptime(date(1970,1,1),time_duration((long)hours, 0 ,(long)(secs - 3600*hours))).date();
В результате в d — нужная дата.
boost 1.34, но думаю в остальных также.
Конечно всё несколько запутано у них, это да.
Здравствуйте, MasterZiv, Вы писали:
MZ>BishopMorton пишет: >> С какого фига Microsoft определили *по дефолту* time_t как 64-bit integer >> http://msdn2.microsoft.com/en-us/library/3b2e7499.aspx
MZ>Патамушта микрасофт !
>> Натолкнулся на эти грабли при переводе старого проекта на MSVS2005 MZ>Гы ... и ты тоже ... MZ>USE_32BIT_TIME_T тебе в помощь... MZ>MySQL кстати только из-за этого на 2005 студии не компилится.
>> Кто как решил для себя решать проблему 2038 года?
MZ>/DUSE_32BIT_TIME_T MZ>sleep( 1000*3600*24*365*20 );
Обнаружили тут прикольный баг в MFC (mfc80.dll)
Если засетить USE_32BIT_TIME_T в MFC проекте, то ::HasFont функция падает (внутри mfc) с Access Violation в Release
Если убрать USE_32BIT_TIME_T то все пучком... такие вот дела
BishopMorton пишет: > Обнаружили тут прикольный баг в MFC (mfc80.dll) > > Если засетить USE_32BIT_TIME_T в MFC проекте, то ::HasFont функция > падает (внутри mfc) с Access Violation в Release > > Если убрать USE_32BIT_TIME_T то все пучком... такие вот дела
Так это не баг, это ж вам надо было MFC пересобрать с USE_32BIT_TIME_T
сначала, а потом с ней уже работать.
