Проблема 2038 года (32 бита)

смотрел?

Вам что, проблем в 2011-ом не хватает?

А вы думаете, к 2038 году 32-битные платформы еще будут существовать?

Вобще логично предположитьчто останутся некоторые монстры и некоторый софт. Как в 2000 году была проблема с двумя разрядами - так и сейчас она может всплыть. Мало ли? Или вы считаете что «Переписать все к чертям» не только у программистов но и у менеджеров?

> Есть ли нормальный/стандартный способ решить проблему 2038 года на 32 битной платформе?

Воспользоваться услугами утилизации старого хлама || закопать.

последствия этой проблемы есть уже сейчас при долгосрочных расчётах. ну там планирование погашения кредита на квартиру… %)

Я считаю, что 32-разрядные монстры не дотянут не то, что до 2038 года, но и до 2020-го. Вымрут же.

А вы думаете, к 2038 году 32-битные платформы еще будут существовать?

Мне меня не волнуют какие системы будут делать в 2038 году. Меня волнует сегодняшний день. Не хочется говорить людям заказчика, что система гавкнется в 2038 году «by design». Скорее всего она до этого года не доживет, но нельзя быть ни в чем уверенным.

планирование погашения кредита на квартиру

Думаю, с этой задачей вам и 64 бит не хватит (т.к. больше 300 миллиардов лет не позволит посчитать) :)

Не хочется говорить людям заказчика, что система гавкнется в 2038 году «by design».

В 64-битной системе - не гавкнется.

смотрел?

Смотрел, но все равно спасибо. Я правда пока не вник, со стороны ядра должна быть какая-то поддержка? Или ядру вообще по барабану.

>последствия этой проблемы есть уже сейчас при долгосрочных расчётах. ну там планирование погашения кредита на квартиру… %)

Или когда нужно посчитать «возраст» конторы, которая образована в 1897-м году :)

>Мне меня не волнуют какие системы будут делать в 2038 году. Меня волнует сегодняшний день. Не хочется говорить людям заказчика, что система гавкнется в 2038 году

Скажи заказчику, что железо нужно проапгрейдить. Делов-то. Или у тебя система, которая стоит много дешевле железа?

А не проще ли в этих целях использовать специально для этого и предназначенные юлианские даты?

>А не проще ли в этих целях использовать специально для этого и предназначенные юлианские даты?

Ну так всю инфраструктуру работы с датами придётся свою писать. По-моему, 64 бита, таки, проще поставить :D Да и элементарно актуальнее сегодня.

Не хочется говорить людям заказчика, что система гавкнется в 2038 году «by design».

Ну так и не говори, делай как все буржуи и достигнешь успеха. А когда припрёт, скосишь под дурачка, делов-то.

> скосишь под дурачка, делов-то.

Косить не надо будет, по возрасту можно будет пройти.

К тому времени или ишак сдохнет, или султан помрёт, или сам откинешься.

что это за турбо-система, если вы лично собираетесь поддерживать ее в течении почти 30 лет? а если не собираетесь, то и хрен с ним. убедиться, что на х64 архитектуре ваш код пашет и забыть.

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

Это что за заказчики такие, что они собираются пользоваться программой аж в 2038 году?

оптимистичный тред )

Это что за заказчики такие, что они собираются пользоваться программой аж в 2038 году?

В принципе на это дело можно и забить. Никто не узнает и не накажет. Просто я хотел сделать все по человечески. Вообще я пишу софт для контроллеров, задействованных в сфере автоматизации электрических подстанций. Поставят черный ящик где-нибудь на подстанции, будет он работать сам по себе, никому до него не будет дела. Вполне возможно, что никто о существовании контроллера не вспомнит аж до 2038 года. Хотя может быть железо сдохнет раньше, не знаю, я программист а не железячник.

С 64 битными контроллерами проблема. Я не свободен в выборе железа.

если правильно перевёл, то должно просто работать на 32х битных системах и 64-битных, где по-прежнему time_t 4 байта.
скачал посмотреть, на моей 64-битной системе make test выдало

make test
t/asctime64.t .............. ok    
t/ctime64.t ................ ok   
t/gmtime64.t ............... ok        
t/mktime64.t ............... # Failed test
# mktime64(140736341324048)
# have: 12344592500
# want: 12344678900
t/mktime64.t ............... Failed 1/17 subtests 
t/negative.t ............... ok    
t/overflow.t ............... ok   
t/safe_year.t .............. ok       
t/seconds_between_years.t .. ok   
t/timegm.t ................. ok    
t/year_limit.t ............. ok   

Test Summary Report
-------------------
t/mktime64.t             (Wstat: 0 Tests: 17 Failed: 1)
  Failed test:  13
Files=10, Tests=284120, 20 wallclock secs (19.56 usr  0.08 sys +  0.32 cusr  0.00 csys = 19.96 CPU)
Result: FAIL
make: *** [tap_tests] Ошибка 1

>что это за турбо-система, если вы лично собираетесь поддерживать ее в течении почти 30 лет?

Elbrus 4 Glonass edition.

скорее всего 32-битная платформа будет модернизирована для встраиваемых систем и проблема 2038 будет решена

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

А я думал, на лоровской машине времени бортовой компутер с 64-битным процом.

> последствия этой проблемы есть уже сейчас при долгосрочных расчётах. ну там планирование погашения кредита на квартиру… %)

Ага, давеча сам хотел спланировать такое и разрядов не хватило. Решил забить. Но вряд ли итог вышел бы иным, если бы хватило. Так что 64 бита не нужно! :)

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

>Есть ли нормальный/стандартный способ решить проблему 2038 года

К этому времени планируется технологическая сингуляртость, т.ч. её решит кто-то другой.

К этому времени планируется технологическая сингуляртость

Футурологи в треде?

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

Если верить википедии, то работники одной атомной электростанции в Канаде до сих пор ловят лулзы с IBM-овского компьютера, 65 года выпуска, управляющего ихним тех. процессом.

> ихним

> > ихним

NXHNM

Можно же, наверное, руками пропатчить ядро...