Search
Write a publication
Pull to refresh

Comments 20

Весьма короткий пост, каждый абзац которого заставляет недоумевать по разным причинам. От "для кого написано" до "причём тут десятичные цифры или разрядность системы"

Это же хорошо, когда что-то заставляет недоумевать. Ошибка встречается только в 64-разрядной версии ОС, так как в 32-битной диапазон значений гораздо уже. Разрядность играет ключевую роль в данном случае.
Вы в курсе, что в 32-битной ОС можно использовать 64-битные числа? Напрямую это не имеет никакого отношения к вопросу. Другое дело, что какой-нибудь time_t в большинстве 32-битных платформ есть 32-битный.
18.446.744.073.709.551.615 (при использовании 20 десятичных цифр) и -9.223.372.036.854.775.808 либо +9.223.372.036.854.775.807 при использовании 19 десятичных цифр
Что означает "при использовании 19/20 десятичных цифр" в данном контексте?
в результате которой получается время раньше, чем 1 января 1970-го года, причем не просто отрицательное, а со значением, на порядок превосходящим ожидаемое время жизни нашей Вселенной
Это вообще непонятно из данной статьи — почему оно так получается то? Почему время раньше получается, если ставится время позже. Ну итд.

Уже все об этом написали. Я ожидал разбор полетов об истинной причине неполадок.
Истинная причина дана, читайте крайний абзац: "виновата одна из возможных проверок системы (вычисление времени последнего звонка или работы батареи), в результате которой получается время раньше, чем 1 января 1970-го года, причем не просто отрицательное, а со значением, на порядок превосходящим ожидаемое время жизни нашей Вселенной, с отображением которого у программы, разумеется, возникают проблемы". Какая конкретно — не уточняется, но суть проблемы и причина понятна.
АРРРРРР!!! Крайний??? Крайний??! С какого краю он крайний? С левого? С правого? С ближнего? С дальнего? С края Вселенной? Достала уже эта «мода» на крайность! Почему вы боитесь слова «последний», которое здесь более уместно? Покажи мне крайний с лева абзац. Понавыдумывают несуществующих правил и запретов…
А особенно забавно с этой крайнофилией в очередях, например, в кабинет врача. Порой очень трудно удержаться от того, чтобы на вопрос "кто крайний" ответить "я", когда сейчас ка краз твоя очередь заходить в кабинет.
виновата одна из возможных проверок системы
Ну так это предположение (как я понимаю слово «возможных»), а не точная причина. «Истинная» — это когда «при таких-то условиях происходит то-то, что вызывает такие-то эффекты».
Что именно было? Насколько вижу причина в той ссылке явно не описана. В этой публикации приводится объяснение: почему именно в х64 и почему проблема имеет место быть, ведь причина во все не в том, что дата 1 января 1970-го, а в том, что некоторые параметры считаются ранее этой даты и образуют, таким образом, большие числа.
Я больше понял из этого комментария: https://geektimes.ru/post/271118/#comment_9025540
Который привел меня в википедию, где уже объясняется проблема более понятным языком, где написано:

… после перезагрузки устройства оно не будет включаться, всё время будет светиться «белое яблоко». Происходит это из-за разницы в часовых поясах, то есть: если перевести время на 1:00 1 января 1970 года в часовом поясе GMT 1:30 или больше, то счётчик UNIX-time уходит в минус, так как отсчёт ведётся от UTC времени, что система понять не в состоянии, вследствие чего счётчик зависает
Опять же, что значит «счётчик зависает»? Счетчик не может зависнуть, он будет исправно считать вперёд независимо от своего значения. Дойдёт до максимума и начнёт счёт с нуля. Возможно, просто надо дождаться когда пройдут эти 3-4 часа и время уже безпроблемно пойдёт с нуля.
Другое дело если алгоритм разработан так что блокирует счётчик времени будучи отрицательным… но с точки зрения программиста мне кажется это очень сомнительным.
Интересно, а как устроены энергонезависимые часы в телефоне? в каком виде там хранится время? Ведь при старте системы время считывается оттуда и проблема тогда должна уйти сама собой просто по прошествии некоторого времени т.к. этот счётчик уж точно не остановить и едва ли он там считает в UNIX-формате.
Пожалуй, это можно назвать лишь УСЛОВИЕМ возникновения проблемы а не причиной. Это всего лишь число, программа не должна вести себя так как это происходит в данном случае. Причина не в числах представляющих эту дату а в неадекватном поведении программы обрабатывающей даты. И врятли система что-то выводит при загрузке да едва ли может возникнуть подобная проблема при выводе даты и даже при её преобразовании. Скорей всего проблема вызвана неправильной работой с памятью, типа под дату выделено всего 4 символа под год, а функция преобразующая дату в текст выдаёт год гораздо большего размера чем 4 символа(а и правда, какой там должен быть год для этой даты, может кто подсчитать?) и нет никакой проверки и ограничения — затирает соседние указатели в результате чего система рушится и перезагружается. И возможно это происходит при попытке записать в системный лог дату события… на уровне ядра поэтому и проблемы такие серьёзные.
Есть много способов убить Iphone всего за 2 секунды
UFO landed and left these words here
А если вернуться в прошлое? Как тогда быть? Для этого и оставили возможность поставить дату, до производства устройства :)
Думаю, у них просто стандартный контрол для даты, и в нем нет ограничений, потому что тот же самый контрол может использоваться для выставления даты рождения контакта (и тогда вполне может понадобится постановка даты раньше 1 января 1970 года).
А вы, часом, не дупутат?
1) причем здесь переполнение или минусовое значение?

1.01.1970 это unix time 0 секунд

поставить раньше (unix time -1 секунда например) вам не позволит DataPicker в настройках телефона.

2) это проблема уже была на телефонах с 32bit процессорами. Для 64bit еще не пофиксили.

3) проблема может быть либо в ядре системы(маловероятно но возможно),
либо в сертификатах которыми подписывают программы.
Sign up to leave a comment.