Как Environment.TickCount переполняется через 25 дней (или 48-49 дней)

Question

При чтении этого вопроса и его ответов Environment.TickCount недостаточно Я запутался.

Они говорят, что Environment.TickCount работает в течение 48-49 дней (OP) (и @Cody Grey говорит 25 дней), но это значение int, поэтому может хранить до 2 147 483 647.

Теперь 1 миллисекунда содержит 10 000 тиков, что означает, что она может удерживать до 214 748,3+ миллисекунд, что составляет 214 + только секунд, что составляет менее 4 минут.

Я что-то упустил?

Кстати, теперь есть Environment.TickCount64, который обеспечивает 64-битное значение.

Answer 1

Для начала TickCount возвращает миллисекунды , а не тики в смысле DateTime.Ticks. Он делает это с точностью, аналогичной системному таймеру, который составляет около 10-16 миллисекунд.

В документации объясняется, как циклы значений:

Поскольку значение TickCount значение свойства представляет собой 32-разрядное целое число со знаком, если система работает непрерывно, TickCount будет увеличиваться с нуля до Int32.MaxValue в течение приблизительно 24,9 дней, затем перейдет к Int32.MinValue, который является отрицательным числом, а затем увеличится до ноль в течение следующих 24,9 дней. Вы можете обойти эту проблему, вызвав функцию Windows GetTickCount, которая сбрасывается в ноль примерно через 49,7 дней, или вызвав функцию GetTickCount64.

По математике мы обнаруживаем, что 24,9 дня - это 2 151 360 000 (по сравнению с Int.MaxValue из 2 147 483 647). MaxValue + |MinValue| дает 4294967295, что, если поделить на 86400000 миллисекунд (1 день), даст около 49,7 дня, как следует из документации.

Источник