PHP: полный мануал с примерами, функциями и ООП

<?php
$input = '15.06.2024';
$date = DateTimeImmutable::createFromFormat('!d.m.Y', $input, new DateTimeZone('UTC'));
if ($date === false) {
    echo "Заявка не принята: дату не удалось разобрать\n";
} else {
    echo 'День заявки: ', $date->format('Y-m-d H:i:s e'), "\n";
}

День заявки: 2024-06-15 00:00:00 UTC

Format !d.m.Y связывает первые две цифры с днём15, следующие — с месяцем6, последние — с годом2024. ! даёт предсказуемые нулевые часы. Фабрика возвращает DateTimeImmutable в date, else вызывает format и использует его строку как подпись заявки. Этот первый вход задан автором; проверка false ещё не достаточна для произвольного текста формы.

<?php
$input = '30.02.2024';
$date = DateTimeImmutable::createFromFormat('!d.m.Y', $input, new DateTimeZone('UTC'));
$issues = DateTimeImmutable::getLastErrors();
$valid = $date !== false
    && ($issues === false || ($issues['warning_count'] === 0 && $issues['error_count'] === 0))
    && $date->format('d.m.Y') === $input;
echo 'В поле: ', $input, "\n";
if ($date !== false) { echo 'Парсер построил: ', $date->format('d.m.Y'), "\n"; }
if ($valid) { echo "День можно использовать в заявке\n"; }
else { echo "Заявка остановлена: исправьте исходную дату\n"; }

В поле: 30.02.2024
Парсер построил: 01.03.2024
Заявка остановлена: исправьте исходную дату

30 февраля превратилось в1 марта, поэтому предупреждение делает valid=false. Нормализованный объект показан для объяснения, но заявка не использует его как согласованный день. && прекращает проверку после false, поэтому исходный date=false не получил бы вызов format. Дополнительно проверяются точный обратный формат, тип исходного поля, допустимая длина и нулевые байты; полный самостоятельный обработчик есть в базовом маршруте дат.

<?php
declare(strict_types=1);

$date = DateTimeImmutable::createFromFormat('Y-m-!d', '2024-06-15', new DateTimeZone('UTC'));
echo $date->format('Y-m-d H:i:s'), "\n";
$kept = DateTimeImmutable::createFromFormat('Y-m-d|', '2024-06-15', new DateTimeZone('UTC'));
echo $kept->format('Y-m-d H:i:s'), "\n";

1970-01-15 00:00:00
2024-06-15 00:00:00

! посередине сбросил уже разобранные год/месяц. | сохранил прочитанные поля. Обычно для поля даты удобнее ! в самом начале.

<?php
$input = '2024-06-15 imported';
$date = DateTimeImmutable::createFromFormat('!Y-m-d+', $input, new DateTimeZone('UTC'));
$issues = DateTimeImmutable::getLastErrors();
echo 'Получено поле: ', $input, "\n";
if ($date !== false) { echo 'Распознан день: ', $date->format('Y-m-d'), "\n"; }
if ($issues !== false && $issues['warning_count'] > 0) {
    echo "Импорт отложен: в поле остался лишний хвост\n";
}

Получено поле: 2024-06-15 imported
Распознан день: 2024-06-15
Импорт отложен: в поле остался лишний хвост

Плюс в конце шаблона разрешил создать объект при лишнем хвосте, заменив ошибку предупреждением. Он не проверил смысл слова imported и не сделал его допустимым по договору импорта. Здесь выбран отказ. Если ваш формат намеренно хранит дату и отметку, разберите и проверьте оба поля по отдельности вместо добавления+ ради исчезновения false.

<?php
declare(strict_types=1);

try { DateTimeImmutable::createFromFormat('!Y-m-d', "2024-06-15\0"); }
catch (ValueError $error) { echo "Недопустимый байт во входе\n"; }

Недопустимый байт во входе

Это отдельный путь исключения поверх возвращаемого false. Проверка типов, ограничение длины и контроль допустимых байтов делают обработчик предсказуемым.

<?php
$date = new DateTimeImmutable('2024-06-15 10:30:00', new DateTimeZone('UTC'));
$label = $date->format('d.m.Y H:i');
echo 'Встреча: ', $label, ' UTC', "\n";
echo 'День для заявки: ', $date->format('Y-m-d'), "\n";

Встреча: 15.06.2024 10:30 UTC
День для заявки: 2024-06-15

Первый format возвращает строку 15.06.2024 10:30 в label. Echo добавляет назначение и зону. Второй вызов читает тот же объект и возвращает 2024-06-15 прямо в ожидающий echo. Точки, дефисы, двоеточие и пробел — разделители; d/m/Y означают день/месяц/год, H/i — час/минуту. Объект и его часы не изменились.

<?php
$date = new DateTimeImmutable('2024-06-15 23:47:09', new DateTimeZone('UTC'));
echo 'Ошибочный шаблон h:m:s: ', $date->format('h:m:s'), "\n";
echo 'Время закрытия H:i:s: ', $date->format('H:i:s'), "\n";

Ошибочный шаблон h:m:s: 11:06:09
Время закрытия H:i:s: 23:47:09

h вывел 11 часов по 12-часовой шкале, m — месяц 06, а не 47 минут. Исправление H:i:s возвращает 23:47:09. Часовой пояс менять не нужно: дата всё время хранила правильные часы. Для 12-часового вывода добавьте a или A, чтобы отличать утро от вечера.

<?php
$date = new DateTimeImmutable('2021-01-01 10:00:00', new DateTimeZone('UTC'));
$week = $date->format('o-\WW');
$filename = 'sales-' . $week . '.csv';
echo 'Продажа от: ', $date->format('d.m.Y'), "\n";
echo 'Имя недельного отчёта: ', $filename, "\n";
echo 'Неверная группа Y-W: ', $date->format('Y-W'), "\n";

Продажа от: 01.01.2021
Имя недельного отчёта: sales-2020-W53.csv
Неверная группа Y-W: 2021-53

W — номер ISO-недели, o — год этой же недели. Первый W после обратного слеша становится буквальной буквой, второй даёт 53. Точка соединяет sales-, полученную строку 2020-W53 и .csv. Пример готовит имя, файл не создаёт. Пятница 1 января относится к последней неделе 2020; Y-W отправил бы её в ошибочную группу 2021-53.

<?php
$date = new DateTimeImmutable('2024-06-15 10:30:00.125456', new DateTimeZone('UTC'));
$apiTime = $date->format(DateTimeInterface::RFC3339_EXTENDED);
echo 'EVT-41 для API: ', $apiTime, "\n";
echo 'EVT-41 для журнала: ', $date->format('Y-m-d H:i:s.u P'), "\n";

EVT-41 для API: 2024-06-15T10:30:00.125+00:00
EVT-41 для журнала: 2024-06-15 10:30:00.125456 +00:00

DateTimeInterface::RFC3339_EXTENDED — именованная константа с готовым шаблоном. Его v оставляет три цифры миллисекунд 125; шаблон с u сохраняет шесть 125456. API получает явно заданную зону и точность, журнал — более подробное время. Это подготовка строк, без сетевой отправки и записи файла. Нужны целые секунды — договоритесь о DATE_ATOM или c; для большой даты за 9999 год нужен расширенный год.

<?php
$date = new DateTimeImmutable('2024-06-15 10:30:00', new DateTimeZone('Europe/Moscow'));
echo 'Время редакции: ', $date->format('d.m.Y H:i P'), "\n";
$utc = DateTimeImmutable::createFromInterface($date)->setTimezone(new DateTimeZone('UTC'));
$headerValue = $utc->format('D, d M Y H:i:s \G\M\T');
echo 'Значение Last-Modified: ', $headerValue, "\n";

Время редакции: 15.06.2024 10:30 +03:00
Значение Last-Modified: Sat, 15 Jun 2024 07:30:00 GMT

CreateFromInterface создаёт независимый Immutable, setTimezone показывает тот же момент в UTC. Только после этого шаблон добавляет буквальные G/M/T: каждый символ защищён обратным слешем от распознавания. D и M дают английские сокращения для этого протокола. Строка готова, но HTTP-заголовок здесь не отправляется. Просто написать GMT к московским 10:30 означало бы сообщить другой момент.

<?php
$date = new DateTimeImmutable('2024-06-15 10:30:00', new DateTimeZone('UTC'));
echo 'До продления: ', $date->format('d.m.Y H:i'), "\n";
$next = $date->modify('+1 day');
echo 'Новое окончание брони: ', $next->format('d.m.Y H:i'), "\n";
echo 'Дата в исходной переменной: ', $date->format('d.m.Y H:i'), "\n";

До продления: 15.06.2024 10:30
Новое окончание брони: 16.06.2024 10:30
Дата в исходной переменной: 15.06.2024 10:30

В строке +1 day знак+ означает движение вперёд,1 — число дней, day — английское слово грамматики даты. Правило применяется к date; возвращённая дата попадает в next и затем в подпись нового срока. Исходный date остаётся 15 июня; next — новый объект. Результат Immutable надо сохранить: в PHP8.5 это дополнительно отмечено атрибутом NoDiscard.

<?php
$date = new DateTimeImmutable('2023-01-31 10:30:00', new DateTimeZone('UTC'));
$plain = $date->modify('+1 month');
$monthEnd = $date->modify('last day of next month');
echo 'Начало расчёта: ', $date->format('d.m.Y H:i'), "\n";
echo 'Обычное +1 month: ', $plain->format('d.m.Y H:i'), "\n";
echo 'По правилу конца месяца: ', $monthEnd->format('d.m.Y H:i'), "\n";

Начало расчёта: 31.01.2023 10:30
Обычное +1 month: 03.03.2023 10:30
По правилу конца месяца: 28.02.2023 10:30

В первом расчёте январь заменяется февралём при дне 31; лишние три дня переносятся в март. Второе правило сразу выбирает последний день февраля. Оба вызова начинают с неизменённого date. Для подписки результат выбирает договор. «Сохранить номер дня, ограничив концом месяца» — ещё одно правило: для 15 января оно даст 15 февраля, а не 28-е.

<?php
$date = new DateTimeImmutable('2024-01-01 00:00:00', new DateTimeZone('UTC'));
$day = $date->modify('2024-06-17');
$meeting = $day->modify('14:30');
echo 'Подтверждение: встреча ', $meeting->format('d.m.Y H:i P'), "\n";

Подтверждение: встреча 17.06.2024 14:30 +00:00

Первый modifier заменяет календарный день на 17 июня, второй — часы и минуты на 14:30. Каждый возврат используется следующим вызовом. Это управляемые автором строки; для поля ввода с обещанным форматом нужен createFromFormat и проверка warnings/errors, а не надежда на строгость гибкого парсера.

<?php
$date = new DateTimeImmutable('2024-06-15 10:30:00', new DateTimeZone('UTC'));
try {
    $next = $date->modify('not a date at all');
    echo 'Продление подтверждено до ', $next->format('d.m.Y H:i'), "\n";
} catch (DateMalformedStringException $error) {
    echo "Продление отменено: правило не разобрано\n";
}
echo 'Действующая бронь до ', $date->format('d.m.Y H:i'), "\n";

Продление отменено: правило не разобрано
Действующая бронь до 15.06.2024 10:30

PHP8.3+. Неверная грамматика бросает исключение до присваивания next, поэтому подтверждение внутри try не печатается. Catch выводит отказ; дальнейший код показывает прежний срок. Валидное, но не соответствующее договору +1 month не обязано бросать исключение: его календарный результат проверяют отдельно.

<?php
$date = new DateTimeImmutable('2024-01-31 10:00:00', new DateTimeZone('UTC'));
for ($number = 1; $number <= 3; $number++) {
    $date = $date->modify('last day of next month');
    echo 'Списание ', $number, ': ', $date->format('d.m.Y H:i'), "\n";
}

Списание 1: 29.02.2024 10:00
Списание 2: 31.03.2024 10:00
Списание 3: 30.04.2024 10:00

Договор здесь явно задаёт последний день каждого месяца. На каждом шаге for number увеличивается, modify создаёт следующий месяц с его настоящим последним днём, присваивание date сохраняет новый объект для следующего шага. Часы 10:00 остаются. Это подготовка расписания, деньги не списываются. Для договора «30-е число, а в коротком месяце последний день» нужно хранить исходное число 30 отдельно: после февраля его нельзя восстановить из одного объекта даты.

<?php
$current = new DateTimeImmutable('2024-06-15 10:00:00', new DateTimeZone('UTC'));
$day = $current->modify('first day of next month');
$startsAt = $day->setTime(0, 0);
echo 'Следующий период начинается: ', $startsAt->format('d.m.Y H:i'), "\n";
echo 'Исходная проверка: ', $current->format('d.m.Y H:i'), "\n";

Следующий период начинается: 01.07.2024 00:00
Исходная проверка: 15.06.2024 10:00

First day of next month выбирает 1 июля, сохраняя 10:00. Отдельный setTime(0,0) устанавливает полночь, потому что договор периода требует её явно. Первый возврат хранится в day, второй — в startsAt; current остался 15 июня 10:00. Так не теряется полезное различие между выбором календарного дня и выбором времени начала.

<?php
$checkIn = new DateTimeImmutable('2024-06-15 00:00:00', new DateTimeZone('UTC'));
$checkOut = new DateTimeImmutable('2024-06-18 00:00:00', new DateTimeZone('UTC'));
$stay = $checkIn->diff($checkOut);
$nights = $stay->days;
$total = $nights * 3000;
echo 'Заезд: ', $checkIn->format('d.m.Y'), '; выезд: ', $checkOut->format('d.m.Y'), "\n";
echo 'Ночей: ', $nights, '; сумма: ', $total, ' руб.', "\n";

Заезд: 15.06.2024; выезд: 18.06.2024
Ночей: 3; сумма: 9000 руб.

Diff возвращает DateInterval в stay; его свойство days для результата diff содержит общее число полных дней. Между полуночами 15 и 18 июня их 3; nights умножается на цену 3000 и даёт 9000. Это правило бронирования календарных ночей, выезд 18-го не добавляет четвёртую ночь. UTC здесь носитель выбранных календарных дней; реальные местные часы заезда/выезда задают отдельно. Ни одна исходная дата не изменилась.

<?php
$now = new DateTimeImmutable('2024-06-18 00:00:00', new DateTimeZone('UTC'));
$deadline = new DateTimeImmutable('2024-06-15 00:00:00', new DateTimeZone('UTC'));
$signed = $now->diff($deadline);
$positive = $now->diff($deadline, true);
if ($signed->invert === 1) {
    echo 'Срок пропущен на ', $signed->days, ' дня', "\n";
}
echo 'Интервал от проверки к сроку: ', $signed->format('%R%a'), "\n";
echo 'Тот же интервал с absolute=true: ', $positive->format('%R%a'), "\n";

Срок пропущен на 3 дня
Интервал от проверки к сроку: -3
Тот же интервал с absolute=true: +3

От 18 июня к 15-му нужно двигаться назад: invert=1, days=3. Эта пара позволяет вывести понятную просрочку. У DateInterval шаблон %R печатает обязательный знак, %a — общее число дней. Absolute=true сбрасывает направление, поэтому получится+3, но срок от этого не стал будущим. Флаг не превращает календарный интервал в абсолютные прошедшие секунды.

<?php
$start = new DateTimeImmutable('2024-03-09 12:00:00', new DateTimeZone('America/New_York'));
$end = new DateTimeImmutable('2024-03-10 12:00:00', new DateTimeZone('America/New_York'));
$calendar = $start->diff($end);
$utcStart = DateTimeImmutable::createFromInterface($start)->setTimezone(new DateTimeZone('UTC'));
$utcEnd = $end->setTimezone(new DateTimeZone('UTC'));
$elapsed = $utcStart->diff($utcEnd);
echo 'По местному расписанию: ', $calendar->format('%a дн. %h ч.'), "\n";
echo 'Фактически прошло: ', $elapsed->format('%a дн. %h ч.'), "\n";
echo 'Для расчёта секунд: ', $end->getTimestamp() - $start->getTimestamp(), "\n";

По местному расписанию: 1 дн. 0 ч.
Фактически прошло: 0 дн. 23 ч.
Для расчёта секунд: 82800

Две встречи идут в полдень соседних местных дней. Весенний перевод часов сократил прошедшее время до 23 часов. Первый diff описывает местный календарный путь; после перевода обеих дат в UTC второй diff показывает прошедший интервал без перехода зоны. Разность timestamp даёт 82800 секунд. Для замера скорости программы используют монотонные часы hrtime: календарные часы системы могут корректироваться.

<?php
$start = new DateTimeImmutable('2024-01-01 00:00:00', new DateTimeZone('UTC'));
$end = new DateTimeImmutable('2024-02-03 00:00:00', new DateTimeZone('UTC'));
if ($end <= $start) {
    echo "Период аренды должен заканчиваться позже начала\n";
} else {
    $period = $start->diff($end);
    $total = $period->days * 100;
    echo 'Календарное описание: ', $period->format('%m мес. %d дн.'), "\n";
    echo 'Оплачиваемых дней: ', $period->days, "\n";
    echo 'При 100 руб. за день: ', $total, ' руб.', "\n";
}

Календарное описание: 1 мес. 2 дн.
Оплачиваемых дней: 33
При 100 руб. за день: 3300 руб.

Оператор <= сравнивает сами даты и не допускает обратный или нулевой период. В интервале m=1 и d=2 — компоненты после выделения полного месяца; days=33 — весь промежуток. Поэтому счёт равен 3300, а не 200 и не 3200. Месяц нельзя автоматически заменить 30 днями. %d у DateInterval означает остаток дней, %a — полный счёт из diff; это отдельный язык формата относительно DateTime::format.

<?php
$createdAt = time();
$expiresAt = $createdAt + 5 * 60;
$checkAt = $createdAt + 2 * 60;
$remaining = max(0, $expiresAt - $checkAt);
echo 'Полный срок кода: ', $expiresAt - $createdAt, " секунд\n";
echo 'При проверке через две минуты осталось: ', $remaining, " секунд\n";
if ($remaining > 0) { echo "Код ещё можно предъявить\n"; }

Полный срок кода: 300 секунд
При проверке через две минуты осталось: 180 секунд
Код ещё можно предъявить

Time прочитал системные часы один раз и вернул целую Unix-секунду в createdAt. Её конкретное число меняется при запуске; относительный результат не меняется. ExpiresAt —срок через 300 секунд. CheckAt явно моделирует проверку через 120 секунд, это не второй вызов часов и не ожидание. Вычитание даёт 180, max не допускает отрицательный остаток. Пример только рассчитывает срок: он не отправляет код и не реализует весь процесс подтверждения.

<?php
function codeStatus(int $expiresAt, int $now): string
{
    if ($now >= $expiresAt) { return 'Код истёк; запросите новый'; }
    return 'Осталось ' . ($expiresAt - $now) . ' секунд';
}
$createdAt = 1704067200;
$expiresAt = $createdAt + 300;
echo 'Создан: ', gmdate('d.m.Y H:i:s', $createdAt), " UTC\n";
echo 'Действует до: ', gmdate('d.m.Y H:i:s', $expiresAt), " UTC (граница исключена)\n";
echo 'Проверка 00:04:30: ', codeStatus($expiresAt, 1704067470), "\n";
echo 'Проверка 00:05:00: ', codeStatus($expiresAt, 1704067500), "\n";

Создан: 01.01.2024 00:00:00 UTC
Действует до: 01.01.2024 00:05:00 UTC (граница исключена)
Проверка 00:04:30: Осталось 30 секунд
Проверка 00:05:00: Код истёк; запросите новый

CreatedAt здесь намеренно фиксированный снимок, не новое чтение текущих часов. В рабочем месте создания вместо него приходит time(), а в месте проверки отдельный time() передают вторым аргументом codeStatus. В первом вызове локальные параметры получают 1704067500 и 1704067470: return возвращает строку с 30 секундами прямо во внешний echo. Во втором now равен expiresAt, поэтому ранний return выбирает отказ. Такая явная передача now позволяет проверять границы без sleep.

<?php
declare(strict_types=1);

$now = time();
$expiresAt = $now + 300;
echo $expiresAt - $now, "\n";

300

Получаем один now и строим TTL5 минут. Повторный time посреди расчета мог бы дать другую секунду и сделать граничный тест нестабильным.

<?php
declare(strict_types=1);

function isExpired(int $expiresAt, int $now): bool
{
    return $now >= $expiresAt;
}
$now = time();
echo isExpired($now - 1, $now) ? "Истек\n" : "Действует\n";

Истек

Проверка границы>= задана явно. В тесте можно заменить now фиксированным числом; реальный токен дополнительно проверяет подпись и назначение.

<?php
$year = 2024;
$month = 2;
$day = 29;
if (checkdate($month, $day, $year)) {
    echo 'Дата доставки принята: ', sprintf('%02d.%02d.%04d', $day, $month, $year), "\n";
} else { echo "Выберите существующий день доставки\n"; }
$year = 2023;
if (!checkdate($month, $day, $year)) {
    echo 'Доставка 29.02.', $year, " не назначена: такого дня нет\n";
}

Дата доставки принята: 29.02.2024
Доставка 29.02.2023 не назначена: такого дня нет

В месте вызова значения 2,29,2024 передаются в параметры month,day,year именно в таком порядке. True выбирает ветку с подписью даты. После изменения year на 2023 ответ false и знак! превращает его в условие отказа. Sprintf только собирает уже проверенные числа в строку; функция checkdate сама ничего не выводит и не переносит день на март.

<?php
declare(strict_types=1);

function calendarDate(int $year, int $month, int $day): ?string
{
    if (!checkdate($month, $day, $year)) { return null; }
    return sprintf('%04d-%02d-%02d', $year, $month, $day);
}
echo calendarDate(2024, 4, 30) ?? 'Ошибка', "\n";
echo calendarDate(2024, 4, 31) ?? 'Ошибка', "\n";

2024-04-30
Ошибка

! отрицает ответ; ?string разрешает null. sprintf формирует строку уже проверенной даты. Эта функция принимает int: HTTP-поля сначала нужно проверить как строки и безопасно преобразовать.

<?php
declare(strict_types=1);

echo checkdate(2, 29, 2024) ? "Да\n" : "Нет\n";
echo checkdate(2, 29, 2026) ? "Да\n" : "Нет\n";

Да
Нет

Удобная граничная проверка для трех отдельных полей формы. Сами поля сначала должны пройти проверку целых и диапазона.

<?php
declare(strict_types=1);

$month = 4;
$day = 31;
$year = 2026;
echo checkdate($month, $day, $year) ? "Дата принята\n" : "Нет такого дня\n";

Нет такого дня

Проверка не нормализует 31 апреля в 1 мая, что удобно для пользовательского ввода. Для прибавления периода применяется другая операция.