В 2038 году произойдет ли сбой UNIX_TIMESTAMP () с неподписанными столбцами Int?

Я всегда старался использовать неподписанные значения всякий раз, когда могу. В результате все мои поля отметок времени не подписаны. Вместо того, чтобы иметь дело с ошибкой 2038 года, с которой все вы столкнетесь через пару десятилетий, кто-то другой может справиться с проблемой 2108 года после того, как я, вероятно, умру или, по крайней мере, на пенсии.

Или я так думал. Тем не менее, до меня дошло, что все мои усилия могут быть совершенно бесполезными в любом случае, когда я полагаюсь на супер удобную функцию MySQL UNIX_TIMESTAMP (), а не на то, чтобы PHP анализировал запрос с помощью time (). Было бы хорошо, если бы UNIX_TIMESTAMP () был достаточно умным (или тупым), чтобы его можно было обернуть, чтобы он все еще был полезен после этого периода, но, очевидно, он просто возвращает 0. (И все это время я думал, что я тупой, используя время ( ) когда гораздо эффективнее разрешить MySQL использовать UNIX_TIMESTAMP ().)

В некоторых случаях я переходил на новый стандарт, который я называю «миллиметрами», то есть числом миллисекунд, прошедших с эпохи Unix, хранящейся в 64-битном числе. Кажется, гораздо лучше компенсировать миллисекунды с точностью до 292 миллионов лет, чем секунд за 292 миллиарда лет. Поскольку большинство серверов обрабатывают большое количество запросов в секунду, может быть важно иметь такой уровень точности, в то время как я подчеркиваю мысль о практическом применении для управления датами события 300 миллионов лет в будущем. (Будет ли вообще существовать человечество?) Кажется, для этого не существует стандарта, поэтому я считаю, что его нужно вручную анализировать с помощью PHP из функции microtime ().

  function millitime () {
$a = microtime();
return substr($a, 11).$a[2].$a[3].$a[4];
}

Итак, у меня есть несколько вопросов:

1. Это правда. Сбой UNIX_TIMESTAMP (), даже если поместить его в 4-байтовое поле без знака?
2. Ожидаете ли вы, что UNIX_TIMESTAMP () может быть обновлен до 2038 года, чтобы обернуть или иным образом исправить эту проблему, или MySQL просто сломается? Как вы думаете, что будет наиболее вероятным способом адаптации MySQL по мере приближения этой даты?
3. Какова самая простая и эффективная альтернатива без знака, когда я знаю, что мне не понадобится больше секунды точности, и нет необходимости использовать систему после 2108? Есть ли в MySQL эквивалент, 64-разрядный или неподписанный, который все еще может храниться в 4-байтовом поле?
4. Каков наилучший (самый быстрый) способ генерации millitime (), как описано выше, для помещения в базу данных или использования в PHP? Не против избиения битов.