Что такое ошибка PHP Year 2038 (Y2K38) и как ее исправить

На сегодняшний день ошибка Y2K38 не так широко известна разработчикам PHP. Проблема 2038 года, обычно называемая «Ошибка тысячелетия Unix» с аббревиатурой Y2K38 (Y обозначает Год, 2K для 2000 и 38 для года), которая приводит к сбою некоторых программ до или в 2038 году. Проблема затрагивает все программное обеспечение и системы (включая PHP), которые хранят системное время в виде 32-разрядного целого числа со знаком (отметка времени) и интерпретируют это число как число секунд с 00:00:00 UTC 1 января 1970 года.

Основная проблема заключается в способности компьютера подсчитывать время в секундах, прошедших до определенной даты (01-01-2038). Поскольку системы на основе Unix измеряют время в секундах с 1 января 1970 года, 03:14:07 UTC 19 января 2038 года равно 2 147 483 647 секундам после 1 января 1970 года. Если они хранятся в вашей системе как 32-битные системы даты и времени, они могут только считать до 2 147 483 647 отдельных положительных значений, что означает, что система не может продолжать считать секунды, прошедшие после этого времени (kaboom для вашего приложения).

Как определить, подвержена ли моя версия PHP этой ошибке?

Чтобы определить, в какой версии PHP вы используете ошибку, вы можете запустить следующий скрипт:


Если напечатанный текст «среда 1 февраля 2040 00:00», тогда ваш PHP был обязательно скомпилирован с использованием версии x64, в противном случае «четверг 01 января 1970 01:00» означает, что в вашей версии PHP есть ошибка.

Мне нужно беспокоиться об этом?

До даты этой статьи нам нужно ждать 20 лет, чтобы увидеть, как эта ошибка начинает проявляться в приложениях. Тем не менее, в этом году ваше приложение, вероятно, больше не будет использоваться, так как его следует рассматривать как «устаревшее», но мы не можем отказаться от его использования. Так что вы можете быть обеспокоены, если ваше приложение планируется использовать в течение столь длительного времени, однако постарайтесь не быть параноиком по этому поводу, по крайней мере, пока.

Как вы, возможно, знаете (или, возможно, нет), в прошлом было много проблем, таких как проблема 2000 года. Так что лучше предупредить, чем лечить, не так ли? И есть несколько способов предотвратить возникновение этой проблемы в вашем проекте.

Возможные решения для PHP

Вы будете хорошо спать по ночам, не беспокоясь о неудаче вашего заявления в 2038 году, если:

1. Вы используете 64-битную ОС с скомпилированной 64-битной версией PHP

Как уже упоминалось, у операционных систем, которые поддерживают архитектуру x64 и используют 64-битную скомпилированную версию PHP, такой проблемы не будет. В течение и после 2038 года это число будет превышать 231 наибольшее число, представляемое длинным целым числом со знаком в 32-разрядных системах, вызывая проблему 2038 года. Поскольку длинное целое число в 64-битных системах использует 64-битные, проблема не существует в 64-битных системах, которые используют модель LP64.

Вы можете протестировать тот же фрагмент, который мы упомянули, чтобы определить проблему в начале статьи на каком-то веб-сервисе, таком как writephponline и вы увидите правильную дату, поскольку они используют версию PHP на основе x64.

2. Вы используете DateTime вместо функций, которые используют метку времени Unix

Если ваш код PHP использует strtotime Функция манипулировать временем, стараться избегать его. PHP представил класс DateTime в версии 5.2 (полная доступность с 5.3), которая исправила ошибку, вызванную проблемой Unix Millenium. Таким образом, вам не нужно запускать 64-битную систему с скомпилированной 64-битной версией PHP. Например, попробуйте запустить исходный фрагмент, но вместо этого используйте класс DateTime:

format($format) .'';
?>

Даже если вы используете x86 (32-битную) версию PHP (по крайней мере с PHP 5.2), дата будет отображаться в среду 1 февраля 2040 00:00, как и ожидалось. DateTime не страдает от проблем Y2K38 и будет легко обрабатывать даты до 31 декабря 9999 года. Возможно (и надеюсь) ваша система не будет использоваться в этом году.

Обратите внимание, что то же самое относится и к другим инструментам, таким как MySQL (ваша база данных должна хранить дату и время вместо меток времени).

Заинтересованы в подробном объяснении ошибки?

Эта проблема имеет глубокую историю, которую мы не рассмотрим в этой простой информативной статье. Именно поэтому, если вас интересует происхождение ошибки, подробное описание, рекомендуем посетить веб-сайт 2038.org Уильям Поркет, основная статья предоставляет интересную информацию о проблеме.

Если вы нашли эту статью полезной и информативной, поделитесь ею с друзьями-разработчиками PHP, чтобы они также знали об этой ошибке.

Ссылка на основную публикацию
Adblock
detector