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

Я читал о проблеме Y2038 и понимаю, что time_t в конечном итоге вернется к самому низкому представимое отрицательное число, потому что оно попытается «увеличить» бит знака.

Согласно этой странице в Википедии, изменение 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 выглядело бы странно) эпохой, и тогда у нас была бы проблема 2038k в... 2038 снова. - person Marc B; 30.01.2011
comment
Вероятно, да. Однако проблема останется прежней — места не хватит. - person Femaref; 30.01.2011

arrow_upward
3
arrow_downward

Здесь есть более фундаментальная проблема, чем использование значений без знака. Если бы мы использовали беззнаковые значения, то получили бы только один дополнительный бит хронометража. Это оказало бы определенно положительное влияние — удвоило бы количество времени, которое мы могли бы хранить, — но тогда у нас возникла бы проблема намного позже в будущем. В более общем смысле, для любого целочисленного значения с фиксированной точностью у нас возникла бы проблема в этом направлении.

Когда в 1970-х годах разрабатывалась UNIX, 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