Времето като цяло число със знак

Четох за проблема Y2038 и разбирам, че time_t в крайна сметка ще се върне към най-ниската представимо отрицателно число, защото ще се опита да "увеличи" знаковия бит.

Според тази страница в Wikipedia, промяната на time_t в цяло число без знак не може да бъде направена, защото това би счупило програми, които обработват ранни дати. (Което има смисъл.)

Въпреки това, не разбирам защо не е направено цяло число без знак на първо място. Защо просто не съхраните 1 януари 1970 г. като нула, а не като някакво смешно отрицателно число?


signed time unsigned year2038
person Maxpm    schedule 29.01.2011    source източник
comment
защото човекът, който го е написал по този начин, е знаел, че това няма да е негов проблем? ;)   -  person Mitch Wheat    schedule 30.01.2011

Отговори (3)


arrow_upward
6
arrow_downward

Тъй като оставянето му да започне със знак −2,147,483,648 е еквивалентно на оставянето му да започне с незнакова 0. Това не променя обхвата на стойностите, които 32-битово цяло число може да съдържа - 32-битово цяло число може да съдържа 4,294,967,296 различни състояния. Проблемът не е началната точка, проблемът е максималната стойност, която може да се задържи от цялото число. Единственият начин да смекчите проблема е да надстроите до 64-битови цели числа.

Освен това (както току-що разбрах): 1970 г. беше зададена като 0, така че можем да се върнем и назад във времето. (достигането до 1901 г. изглеждаше достатъчно по това време). Ако останаха неподписани, епохата щеше да започне от 1901 г., за да можем да се върнем от 1970 г., и отново щяхме да имаме същия проблем.

person Femaref    schedule 29.01.2011
comment
Аз разбирам, че. Но не би ли било по-интуитивно като цяло число без знак? - person Maxpm; 30.01.2011
comment
Е, ако останаха неподписани, щяха да направят 1900 г. (1901 г. би изглеждало странно) епоха и тогава щяхме да имаме проблема y2038k при... 2038 г. отново. - person Marc B; 30.01.2011
comment
Вероятно, да. Проблемът обаче ще остане същият - мястото ще свърши. - person Femaref; 30.01.2011

arrow_upward
3
arrow_downward

Тук има по-фундаментален проблем от използването на стойности без знак. Ако използвахме стойности без знак, тогава ще получим само още един бит отчитане на времето. Това определено би имало положително въздействие - би удвоило времето, което можем да запазим - но тогава ще имаме проблем много по-късно в бъдещето. По-общо казано, за всяка целочислена стойност с фиксирана точност бихме имали проблем по този начин.

Когато UNIX се разработваше през 70-те години, 60-годишният часовник звучеше добре, въпреки че очевидно 120-годишен часовник би бил по-добър. Ако бяха използвали повече битове, тогава щяхме да имаме много по-дълъг часовник - да кажем 1000 години - но след изтичането на толкова много време щяхме да се върнем в същата връзка и вероятно щяхме да се замислим и да кажем "защо не са използвай повече битове?"

person templatetypedef    schedule 29.01.2011

arrow_upward
1
arrow_downward

Тъй като не всички системи трябва да се справят само с "минали" и "бъдещи" стойности. Дори през 70-те, когато Unix е създаден и системата за време е дефинирана, те трябваше да се справят с дати от 60-те или по-рано. И така, цяло число със знак имаше смисъл.

След като всички преминат към 64-битови time_t, няма да се налага да се тревожим за проблем от типа y2038k за още около 2 милиарда 136-годишни периоди.

person Marc B    schedule 29.01.2011