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

<?php
$zone = new DateTimeZone('Europe/Moscow');
$meeting = new DateTime('2024-06-15 10:30:00', $zone);
$label = $meeting->format('d.m.Y H:i:s P');
echo 'Подтверждена встреча: ', $label, "\n";

Подтверждена встреча: 15.06.2024 10:30:00 +03:00

Zone создан первым и передан вторым аргументом. New возвращает объект в meeting; format читает этот объект и возвращает строку в label. Только echo отправляет её в вывод. Секунды заданы явно, поэтому результат не зависит от времени запуска. Правила Europe/Moscow на этой дате дают смещение +03:00.

<?php
$incoming = new DateTime('2024-06-15T10:30:00+02:00', new DateTimeZone('Asia/Tokyo'));
echo 'Получено со смещением: ', $incoming->format('d.m.Y H:i P'), "\n";
$tokyo = $incoming->setTimezone(new DateTimeZone('Asia/Tokyo'));
echo 'Для участника в Токио: ', $tokyo->format('d.m.Y H:i P'), "\n";
$epoch = new DateTime('@0', new DateTimeZone('Asia/Tokyo'));
echo 'Начало Unix: ', $epoch->format('Y-m-d H:i P'), "\n";

Получено со смещением: 15.06.2024 10:30 +02:00
Для участника в Токио: 15.06.2024 17:30 +09:00
Начало Unix: 1970-01-01 00:00 +00:00

В первой строке +02:00 уже задаёт смысл входных часов, поэтому второй аргумент Tokyo не переопределяет его. Отдельный setTimezone сохраняет момент и показывает17:30 +09:00. У DateTime меняется сам incoming; переменная tokyo обозначает этот же изменённый объект. Строка @0 означает нулевую Unix-метку: она создаётся в UTC независимо от переданного Tokyo. @ внутри строки здесь часть формата даты, а не оператор подавления ошибок PHP.

<?php
$input = '2024-02-30';
$date = new DateTime($input, new DateTimeZone('UTC'));
$problems = DateTime::getLastErrors();
echo 'Запрошено: ', $input, "\n";
echo 'Построен объект: ', $date->format('Y-m-d'), "\n";
if ($problems !== false && $problems['warning_count'] > 0) {
    echo "Встреча не сохранена: исходного дня нет в календаре\n";
}

Запрошено: 2024-02-30
Построен объект: 2024-03-01
Встреча не сохранена: исходного дня нет в календаре

2024 год високосный: после29 февраля лишний день попал на1 марта. Конструктор смог создать объект, но getLastErrors сохранил предупреждение. Пример показывает нормализованную дату для разбора ошибки и отклоняет её для бронирования. Для фиксированного поля удобнее createFromFormat с проверкой диагностики и обратного формата.

<?php
try {
    $meeting = new DateTime('not-a-date-at-all', new DateTimeZone('UTC'));
    echo 'Встреча записана: ', $meeting->format('d.m.Y H:i'), "\n";
} catch (Exception $error) {
    echo "Встреча не создана: строку даты невозможно разобрать\n";
}
echo "Можно проверить следующую заявку\n";

Встреча не создана: строку даты невозможно разобрать
Можно проверить следующую заявку

New не вернул объект: присваивание meeting и строка подтверждения не завершились. Catch даёт понятный отказ, после него выполняется следующая строка. Базовый Exception позволяет этому опыту работать и в PHP8.2; с8.3 конкретная ошибка — DateMalformedStringException, её можно перехватывать отдельно. Внешнему посетителю не выводится внутреннее сообщение с произвольным исходным текстом.

<?php
$timestamp = 1704067200.125;
$eventAt = DateTime::createFromTimestamp($timestamp);
echo 'Событие EVT-41: ', $eventAt->format('Y-m-d H:i:s.u P'), "\n";

Событие EVT-41: 2024-01-01 00:00:00.125000 +00:00

PHP8.4+. Аргумент содержит секунды Unix; дробь0.125 — одна восьмая секунды. Фабрика возвращает объект в eventAt, format с u создаёт шесть цифр микросекунд, а echo добавляет идентификатор события. Timestamp не зависит от локальной зоны сервера. Float имеет ограниченную точность: произвольные большие дробные числа не обещают сохранения всех цифр.

<?php
declare(strict_types=1);

class EventTime extends DateTime {}
$date = EventTime::createFromTimestamp(0);
echo get_class($date), "\n", $date->format('Y-m-d'), "\n";

EventTime
1970-01-01

static в сигнатуре означает класс вызова, а не то, что объект глобален. Метод с :: вызывается у имени класса и создаёт экземпляр.

<?php
$timestamp = INF;
try {
    $eventAt = DateTime::createFromTimestamp($timestamp);
    echo 'Событие EVT-41: ', $eventAt->format('Y-m-d H:i:s'), "\n";
} catch (DateRangeError $error) {
    echo "Событие EVT-41 не принято: время вне диапазона\n";
}

Событие EVT-41 не принято: время вне диапазона

PHP8.4+. Бесконечность не обозначает конкретный момент и вызывает DateRangeError до возврата объекта. Строка подтверждения события пропущена; catch сообщает об отказе именно этой записи. Для внешнего числа сначала проверяют тип, конечность, допустимый диапазон и единицы, а не заменяют невозможную дату текущим временем.

<?php
$zone = new DateTimeZone('Europe/Moscow');
$meeting = new DateTimeImmutable('2024-06-15 10:30:00', $zone);
$label = $meeting->format('d.m.Y H:i:s P');
echo 'Подтверждена встреча: ', $label, "\n";

Подтверждена встреча: 15.06.2024 10:30:00 +03:00

Zone создан первым и передан вторым аргументом. New возвращает объект в meeting; format читает этот объект и возвращает строку в label. Только echo отправляет её в вывод. Секунды заданы явно, поэтому результат не зависит от времени запуска. Правила Europe/Moscow на этой дате дают смещение +03:00.

<?php
$incoming = new DateTimeImmutable('2024-06-15T10:30:00+02:00', new DateTimeZone('Asia/Tokyo'));
echo 'Получено со смещением: ', $incoming->format('d.m.Y H:i P'), "\n";
$tokyo = $incoming->setTimezone(new DateTimeZone('Asia/Tokyo'));
echo 'Для участника в Токио: ', $tokyo->format('d.m.Y H:i P'), "\n";
$epoch = new DateTimeImmutable('@0', new DateTimeZone('Asia/Tokyo'));
echo 'Начало Unix: ', $epoch->format('Y-m-d H:i P'), "\n";

Получено со смещением: 15.06.2024 10:30 +02:00
Для участника в Токио: 15.06.2024 17:30 +09:00
Начало Unix: 1970-01-01 00:00 +00:00

В первой строке +02:00 уже задаёт смысл входных часов, поэтому второй аргумент Tokyo не переопределяет его. Отдельный setTimezone сохраняет момент и показывает17:30 +09:00. У Immutable возвращается другой объект; incoming остаётся в исходном представлении. Строка @0 означает нулевую Unix-метку: она создаётся в UTC независимо от переданного Tokyo. @ внутри строки здесь часть формата даты, а не оператор подавления ошибок PHP.

<?php
$input = '2024-02-30';
$date = new DateTimeImmutable($input, new DateTimeZone('UTC'));
$problems = DateTimeImmutable::getLastErrors();
echo 'Запрошено: ', $input, "\n";
echo 'Построен объект: ', $date->format('Y-m-d'), "\n";
if ($problems !== false && $problems['warning_count'] > 0) {
    echo "Встреча не сохранена: исходного дня нет в календаре\n";
}

Запрошено: 2024-02-30
Построен объект: 2024-03-01
Встреча не сохранена: исходного дня нет в календаре

2024 год високосный: после29 февраля лишний день попал на1 марта. Конструктор смог создать объект, но getLastErrors сохранил предупреждение. Пример показывает нормализованную дату для разбора ошибки и отклоняет её для бронирования. Для фиксированного поля удобнее createFromFormat с проверкой диагностики и обратного формата.

<?php
try {
    $meeting = new DateTimeImmutable('not-a-date-at-all', new DateTimeZone('UTC'));
    echo 'Встреча записана: ', $meeting->format('d.m.Y H:i'), "\n";
} catch (Exception $error) {
    echo "Встреча не создана: строку даты невозможно разобрать\n";
}
echo "Можно проверить следующую заявку\n";

Встреча не создана: строку даты невозможно разобрать
Можно проверить следующую заявку

New не вернул объект: присваивание meeting и строка подтверждения не завершились. Catch даёт понятный отказ, после него выполняется следующая строка. Базовый Exception позволяет этому опыту работать и в PHP8.2; с8.3 конкретная ошибка — DateMalformedStringException, её можно перехватывать отдельно. Внешнему посетителю не выводится внутреннее сообщение с произвольным исходным текстом.

<?php
$timestamp = 1704067200.125;
$eventAt = DateTimeImmutable::createFromTimestamp($timestamp);
echo 'Событие EVT-41: ', $eventAt->format('Y-m-d H:i:s.u P'), "\n";

Событие EVT-41: 2024-01-01 00:00:00.125000 +00:00

PHP8.4+. Аргумент содержит секунды Unix; дробь0.125 — одна восьмая секунды. Фабрика возвращает объект в eventAt, format с u создаёт шесть цифр микросекунд, а echo добавляет идентификатор события. Timestamp не зависит от локальной зоны сервера. Float имеет ограниченную точность: произвольные большие дробные числа не обещают сохранения всех цифр.

<?php
declare(strict_types=1);

class EventTime extends DateTimeImmutable {}
$date = EventTime::createFromTimestamp(0);
echo get_class($date), "\n", $date->format('Y-m-d'), "\n";

EventTime
1970-01-01

static в сигнатуре означает класс вызова, а не то, что объект глобален. Метод с :: вызывается у имени класса и создаёт экземпляр.

<?php
$timestamp = INF;
try {
    $eventAt = DateTimeImmutable::createFromTimestamp($timestamp);
    echo 'Событие EVT-41: ', $eventAt->format('Y-m-d H:i:s'), "\n";
} catch (DateRangeError $error) {
    echo "Событие EVT-41 не принято: время вне диапазона\n";
}

Событие EVT-41 не принято: время вне диапазона

PHP8.4+. Бесконечность не обозначает конкретный момент и вызывает DateRangeError до возврата объекта. Строка подтверждения события пропущена; catch сообщает об отказе именно этой записи. Для внешнего числа сначала проверяют тип, конечность, допустимый диапазон и единицы, а не заменяют невозможную дату текущим временем.

<?php
$original = new DateTimeImmutable('2024-06-15 10:30:00.125000', new DateTimeZone('Europe/Moscow'));
$converted = DateTime::createFromImmutable($original);
$reminder = $converted->modify('+1 day');
echo 'Исходная встреча: ', $original->format('Y-m-d H:i:s.u e'), "\n";
echo 'Напоминание: ', $reminder->format('Y-m-d H:i:s.u e'), "\n";
echo 'Преобразованный вариант теперь: ', $converted->format('Y-m-d'), "\n";

Исходная встреча: 2024-06-15 10:30:00.125000 Europe/Moscow
Напоминание: 2024-06-16 10:30:00.125000 Europe/Moscow
Преобразованный вариант теперь: 2024-06-16

Фабрика получает original и возвращает независимый объект converted с теми же календарём, микросекундами и зоной. Поэтому дальнейший перенос не изменяет исходную встречу. Converted — DateTime: modify меняет его самого, reminder обозначает этот же результат16 июня. Сериализация, промежуточная строка format и повторный разбор для такого преобразования не нужны.

<?php
declare(strict_types=1);

class LocalDate extends DateTime {}
$original = new DateTimeImmutable('2024-01-01', new DateTimeZone('UTC'));
$converted = LocalDate::createFromImmutable($original);
echo get_class($converted), "\n";

LocalDate

Проверка выполнена на PHP 8.5.11. createFromInterface фактически сохраняет класс вызова, хотя опубликованный возвращаемый тип указан как базовый. Это согласуется со stub PHP 8.5.11: в нём стоит TODO уточнить тип на static. У createFromMutable/Immutable изменение на класс вызова отдельно отмечено с PHP 8.0.

<?php
class BookingDate extends DateTime {
    public string $bookingId;
    public function __construct(string $bookingId) {
        $this->bookingId = $bookingId;
        parent::__construct('2024-06-15 10:30:00', new DateTimeZone('UTC'));
    }
}
$source = new DateTimeImmutable('2024-06-15 10:30:00', new DateTimeZone('UTC'));
$converted = BookingDate::createFromImmutable($source);
echo 'Фабрика создала дату: ', $converted->format('d.m.Y H:i'), "\n";
try { echo 'Бронь: ' . $converted->bookingId . "\n"; }
catch (Error $error) { echo "Номер брони отсутствует: конструктор BookingDate не выполнялся\n"; }
$booking = new BookingDate('B-41');
echo 'Обычное создание: ', $booking->bookingId, ', ', $booking->format('d.m.Y H:i'), "\n";

Фабрика создала дату: 15.06.2024 10:30
Номер брони отсутствует: конструктор BookingDate не выполнялся
Обычное создание: B-41, 15.06.2024 10:30

Это отдельная ступень после наследования: extends создаёт подкласс, public string требует инициализированного поля, parent::__construct заполняет родительскую дату. Фабрика создаёт внутреннее календарное значение, обходя пользовательский конструктор, поэтому bookingId не заполнен. Чтение поля вызывает Error до echo готовой строки. Обычный new BookingDate(B-41) запускает конструктор и даёт настоящую подпись брони. Практически часто проще хранить объект даты в отдельном объекте брони, чем наследовать DateTime ради дополнительного поля.

<?php
$original = new DateTime('2024-06-15 10:30:00.125000', new DateTimeZone('Europe/Moscow'));
$converted = DateTimeImmutable::createFromMutable($original);
$reminder = $converted->modify('+1 day');
echo 'Исходная встреча: ', $original->format('Y-m-d H:i:s.u e'), "\n";
echo 'Напоминание: ', $reminder->format('Y-m-d H:i:s.u e'), "\n";
echo 'Преобразованный вариант теперь: ', $converted->format('Y-m-d'), "\n";

Исходная встреча: 2024-06-15 10:30:00.125000 Europe/Moscow
Напоминание: 2024-06-16 10:30:00.125000 Europe/Moscow
Преобразованный вариант теперь: 2024-06-15

Фабрика получает original и возвращает независимый объект converted с теми же календарём, микросекундами и зоной. Поэтому дальнейший перенос не изменяет исходную встречу. Converted — Immutable: modify создаёт ещё один объект reminder, converted остаётся15 июня. Сериализация, промежуточная строка format и повторный разбор для такого преобразования не нужны.

<?php
declare(strict_types=1);

class LocalDate extends DateTimeImmutable {}
$original = new DateTime('2024-01-01', new DateTimeZone('UTC'));
$converted = LocalDate::createFromMutable($original);
echo get_class($converted), "\n";

LocalDate

Проверка выполнена на PHP 8.5.11. createFromInterface фактически сохраняет класс вызова, хотя опубликованный возвращаемый тип указан как базовый. Это согласуется со stub PHP 8.5.11: в нём стоит TODO уточнить тип на static. У createFromMutable/Immutable изменение на класс вызова отдельно отмечено с PHP 8.0.

<?php
class BookingDate extends DateTimeImmutable {
    public string $bookingId;
    public function __construct(string $bookingId) {
        $this->bookingId = $bookingId;
        parent::__construct('2024-06-15 10:30:00', new DateTimeZone('UTC'));
    }
}
$source = new DateTime('2024-06-15 10:30:00', new DateTimeZone('UTC'));
$converted = BookingDate::createFromMutable($source);
echo 'Фабрика создала дату: ', $converted->format('d.m.Y H:i'), "\n";
try { echo 'Бронь: ' . $converted->bookingId . "\n"; }
catch (Error $error) { echo "Номер брони отсутствует: конструктор BookingDate не выполнялся\n"; }
$booking = new BookingDate('B-41');
echo 'Обычное создание: ', $booking->bookingId, ', ', $booking->format('d.m.Y H:i'), "\n";

Фабрика создала дату: 15.06.2024 10:30
Номер брони отсутствует: конструктор BookingDate не выполнялся
Обычное создание: B-41, 15.06.2024 10:30

Это отдельная ступень после наследования: extends создаёт подкласс, public string требует инициализированного поля, parent::__construct заполняет родительскую дату. Фабрика создаёт внутреннее календарное значение, обходя пользовательский конструктор, поэтому bookingId не заполнен. Чтение поля вызывает Error до echo готовой строки. Обычный new BookingDate(B-41) запускает конструктор и даёт настоящую подпись брони. Практически часто проще хранить объект даты в отдельном объекте брони, чем наследовать DateTime ради дополнительного поля.

<?php
$original = new DateTime('2024-06-15 10:30:00.125000', new DateTimeZone('Europe/Moscow'));
$converted = DateTime::createFromInterface($original);
$reminder = $converted->modify('+1 day');
echo 'Исходная встреча: ', $original->format('Y-m-d H:i:s.u e'), "\n";
echo 'Напоминание: ', $reminder->format('Y-m-d H:i:s.u e'), "\n";
echo 'Преобразованный вариант теперь: ', $converted->format('Y-m-d'), "\n";

Исходная встреча: 2024-06-15 10:30:00.125000 Europe/Moscow
Напоминание: 2024-06-16 10:30:00.125000 Europe/Moscow
Преобразованный вариант теперь: 2024-06-16

Фабрика получает original и возвращает независимый объект converted с теми же календарём, микросекундами и зоной. Поэтому дальнейший перенос не изменяет исходную встречу. Converted — DateTime: modify меняет его самого, reminder обозначает этот же результат16 июня. Сериализация, промежуточная строка format и повторный разбор для такого преобразования не нужны.

<?php
declare(strict_types=1);

class LocalDate extends DateTime {}
$original = new DateTime('2024-01-01', new DateTimeZone('UTC'));
$converted = LocalDate::createFromInterface($original);
echo get_class($converted), "\n";

LocalDate

Проверка выполнена на PHP 8.5.11. createFromInterface фактически сохраняет класс вызова, хотя опубликованный возвращаемый тип указан как базовый. Это согласуется со stub PHP 8.5.11: в нём стоит TODO уточнить тип на static. У createFromMutable/Immutable изменение на класс вызова отдельно отмечено с PHP 8.0.

<?php
class BookingDate extends DateTime {
    public string $bookingId;
    public function __construct(string $bookingId) {
        $this->bookingId = $bookingId;
        parent::__construct('2024-06-15 10:30:00', new DateTimeZone('UTC'));
    }
}
$source = new DateTime('2024-06-15 10:30:00', new DateTimeZone('UTC'));
$converted = BookingDate::createFromInterface($source);
echo 'Фабрика создала дату: ', $converted->format('d.m.Y H:i'), "\n";
try { echo 'Бронь: ' . $converted->bookingId . "\n"; }
catch (Error $error) { echo "Номер брони отсутствует: конструктор BookingDate не выполнялся\n"; }
$booking = new BookingDate('B-41');
echo 'Обычное создание: ', $booking->bookingId, ', ', $booking->format('d.m.Y H:i'), "\n";

Фабрика создала дату: 15.06.2024 10:30
Номер брони отсутствует: конструктор BookingDate не выполнялся
Обычное создание: B-41, 15.06.2024 10:30

Это отдельная ступень после наследования: extends создаёт подкласс, public string требует инициализированного поля, parent::__construct заполняет родительскую дату. Фабрика создаёт внутреннее календарное значение, обходя пользовательский конструктор, поэтому bookingId не заполнен. Чтение поля вызывает Error до echo готовой строки. Обычный new BookingDate(B-41) запускает конструктор и даёт настоящую подпись брони. Практически часто проще хранить объект даты в отдельном объекте брони, чем наследовать DateTime ради дополнительного поля.

<?php
$original = new DateTime('2024-06-15 10:30:00.125000', new DateTimeZone('Europe/Moscow'));
$converted = DateTimeImmutable::createFromInterface($original);
$reminder = $converted->modify('+1 day');
echo 'Исходная встреча: ', $original->format('Y-m-d H:i:s.u e'), "\n";
echo 'Напоминание: ', $reminder->format('Y-m-d H:i:s.u e'), "\n";
echo 'Преобразованный вариант теперь: ', $converted->format('Y-m-d'), "\n";

Исходная встреча: 2024-06-15 10:30:00.125000 Europe/Moscow
Напоминание: 2024-06-16 10:30:00.125000 Europe/Moscow
Преобразованный вариант теперь: 2024-06-15

Фабрика получает original и возвращает независимый объект converted с теми же календарём, микросекундами и зоной. Поэтому дальнейший перенос не изменяет исходную встречу. Converted — Immutable: modify создаёт ещё один объект reminder, converted остаётся15 июня. Сериализация, промежуточная строка format и повторный разбор для такого преобразования не нужны.

<?php
declare(strict_types=1);

class LocalDate extends DateTimeImmutable {}
$original = new DateTime('2024-01-01', new DateTimeZone('UTC'));
$converted = LocalDate::createFromInterface($original);
echo get_class($converted), "\n";

LocalDate

Проверка выполнена на PHP 8.5.11. createFromInterface фактически сохраняет класс вызова, хотя опубликованный возвращаемый тип указан как базовый. Это согласуется со stub PHP 8.5.11: в нём стоит TODO уточнить тип на static. У createFromMutable/Immutable изменение на класс вызова отдельно отмечено с PHP 8.0.

<?php
class BookingDate extends DateTimeImmutable {
    public string $bookingId;
    public function __construct(string $bookingId) {
        $this->bookingId = $bookingId;
        parent::__construct('2024-06-15 10:30:00', new DateTimeZone('UTC'));
    }
}
$source = new DateTime('2024-06-15 10:30:00', new DateTimeZone('UTC'));
$converted = BookingDate::createFromInterface($source);
echo 'Фабрика создала дату: ', $converted->format('d.m.Y H:i'), "\n";
try { echo 'Бронь: ' . $converted->bookingId . "\n"; }
catch (Error $error) { echo "Номер брони отсутствует: конструктор BookingDate не выполнялся\n"; }
$booking = new BookingDate('B-41');
echo 'Обычное создание: ', $booking->bookingId, ', ', $booking->format('d.m.Y H:i'), "\n";

Фабрика создала дату: 15.06.2024 10:30
Номер брони отсутствует: конструктор BookingDate не выполнялся
Обычное создание: B-41, 15.06.2024 10:30

Это отдельная ступень после наследования: extends создаёт подкласс, public string требует инициализированного поля, parent::__construct заполняет родительскую дату. Фабрика создаёт внутреннее календарное значение, обходя пользовательский конструктор, поэтому bookingId не заполнен. Чтение поля вызывает Error до echo готовой строки. Обычный new BookingDate(B-41) запускает конструктор и даёт настоящую подпись брони. Практически часто проще хранить объект даты в отдельном объекте брони, чем наследовать DateTime ради дополнительного поля.

<?php
$date = date_create('2024-06-15 10:30:00', new DateTimeZone('UTC'));
if ($date === false) {
    echo "Встреча не создана: исправьте дату\n";
} else {
    echo 'Встреча в UTC: ', $date->format('d.m.Y H:i'), "\n";
}

Встреча в UTC: 15.06.2024 10:30

В отличие от new, этот вызов имеет два обычных варианта результата: объект или false. Здесь получен DateTime, проверка false не сработала, else вызывает format и использует возвращённую строку в подтверждении. Процедурное имя не делает результат строкой. Обычные операции изменения сохраняют договор класса: mutable меняется, immutable возвращает новый вариант.

<?php
$date = date_create('not-a-date-at-all', new DateTimeZone('UTC'));
$errors = date_get_last_errors();
if ($date === false) {
    echo "Заявка ожидает исправления даты\n";
    if ($errors !== false && $errors['error_count'] > 0) {
        echo "Причина: строка не соответствует грамматике даты\n";
    }
} else {
    echo 'Подтверждено: ', $date->format('d.m.Y H:i'), "\n";
}

Заявка ожидает исправления даты
Причина: строка не соответствует грамматике даты

Неразбираемая строка дала false, а date_get_last_errors сразу сохранил её диагностику. Ветка отказа не обращается к методу false и не подставляет сегодняшний день. Удачная ветка остаётся в полном примере, чтобы было видно место использования настоящего объекта. Предупреждения о календарном переполнении проверяют отдельно: объект может существовать, хотя исходный день был невозможен.

<?php
$date = date_create_immutable('2024-06-15 10:30:00', new DateTimeZone('UTC'));
if ($date === false) {
    echo "Встреча не создана: исправьте дату\n";
} else {
    echo 'Встреча в UTC: ', $date->format('d.m.Y H:i'), "\n";
}

Встреча в UTC: 15.06.2024 10:30

В отличие от new, этот вызов имеет два обычных варианта результата: объект или false. Здесь получен DateTimeImmutable, проверка false не сработала, else вызывает format и использует возвращённую строку в подтверждении. Процедурное имя не делает результат строкой. Обычные операции изменения сохраняют договор класса: mutable меняется, immutable возвращает новый вариант.

<?php
$date = date_create_immutable('not-a-date-at-all', new DateTimeZone('UTC'));
$errors = date_get_last_errors();
if ($date === false) {
    echo "Заявка ожидает исправления даты\n";
    if ($errors !== false && $errors['error_count'] > 0) {
        echo "Причина: строка не соответствует грамматике даты\n";
    }
} else {
    echo 'Подтверждено: ', $date->format('d.m.Y H:i'), "\n";
}

Заявка ожидает исправления даты
Причина: строка не соответствует грамматике даты

Неразбираемая строка дала false, а date_get_last_errors сразу сохранил её диагностику. Ветка отказа не обращается к методу false и не подставляет сегодняшний день. Удачная ветка остаётся в полном примере, чтобы было видно место использования настоящего объекта. Предупреждения о календарном переполнении проверяют отдельно: объект может существовать, хотя исходный день был невозможен.

<?php
$input = '15.06.2024';
$date = DateTime::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. ! даёт предсказуемые нулевые часы. Фабрика возвращает DateTime в date, else вызывает format и использует его строку как подпись заявки. Этот первый вход задан автором; проверка false ещё не достаточна для произвольного текста формы.

<?php
$input = '30.02.2024';
$date = DateTime::createFromFormat('!d.m.Y', $input, new DateTimeZone('UTC'));
$issues = DateTime::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 = DateTime::createFromFormat('Y-m-!d', '2024-06-15', new DateTimeZone('UTC'));
echo $date->format('Y-m-d H:i:s'), "\n";
$kept = DateTime::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 = DateTime::createFromFormat('!Y-m-d+', $input, new DateTimeZone('UTC'));
$issues = DateTime::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 { DateTime::createFromFormat('!Y-m-d', "2024-06-15\0"); }
catch (ValueError $error) { echo "Недопустимый байт во входе\n"; }

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

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

<?php
$input = '15.06.2024';
$date = date_create_from_format('!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. ! даёт предсказуемые нулевые часы. Фабрика возвращает DateTime в date, else вызывает format и использует его строку как подпись заявки. Этот первый вход задан автором; проверка false ещё не достаточна для произвольного текста формы.

<?php
$input = '30.02.2024';
$date = date_create_from_format('!d.m.Y', $input, new DateTimeZone('UTC'));
$issues = DateTime::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 = date_create_from_format('Y-m-!d', '2024-06-15', new DateTimeZone('UTC'));
echo $date->format('Y-m-d H:i:s'), "\n";
$kept = date_create_from_format('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 = date_create_from_format('!Y-m-d+', $input, new DateTimeZone('UTC'));
$issues = DateTime::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 { date_create_from_format('!Y-m-d', "2024-06-15\0"); }
catch (ValueError $error) { echo "Недопустимый байт во входе\n"; }

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

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

<?php
$input = '15.06.2024';
$date = date_create_immutable_from_format('!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 = date_create_immutable_from_format('!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 = date_create_immutable_from_format('Y-m-!d', '2024-06-15', new DateTimeZone('UTC'));
echo $date->format('Y-m-d H:i:s'), "\n";
$kept = date_create_immutable_from_format('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 = date_create_immutable_from_format('!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 { date_create_immutable_from_format('!Y-m-d', "2024-06-15\0"); }
catch (ValueError $error) { echo "Недопустимый байт во входе\n"; }

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

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

<?php
$input = '2024-02-30';
$date = DateTimeImmutable::createFromFormat('!Y-m-d', $input, new DateTimeZone('UTC'));
$issues = DateTime::getLastErrors();
echo 'Введено: ', $input, "\n";
if ($date !== false) { echo 'Получено у парсера: ', $date->format('Y-m-d'), "\n"; }
if ($issues !== false && $issues['warning_count'] > 0) {
    echo "Не принимаем дату: парсер сообщил о календарном исправлении\n";
}

Введено: 2024-02-30
Получено у парсера: 2024-03-01
Не принимаем дату: парсер сообщил о календарном исправлении

GetLastErrors не получает date параметром: он читает состояние последней операции разбора. Возвращённый массив сохранён в issues. У этого входа объект есть и error_count=0, однако предупреждение запрещает использовать его как исходный день. Поэтому проверять только ошибки недостаточно.

<?php
$first = DateTimeImmutable::createFromFormat('!Y-m-d', '2024-02-30', new DateTimeZone('UTC'));
$saved = DateTime::getLastErrors();
$second = DateTimeImmutable::createFromFormat('!Y-m-d', '2024-02-29', new DateTimeZone('UTC'));
$latest = DateTime::getLastErrors();
if ($second !== false && $latest === false) {
    echo 'Второе поле принято: ', $second->format('d.m.Y'), "\n";
}
if ($saved !== false && $saved['warning_count'] > 0) {
    echo "Первое поле 2024-02-30 осталось отклонённым в сохранённом отчёте\n";
}
if ($latest === false) { echo "Текущая диагностика уже не содержит первого предупреждения\n"; }

Второе поле принято: 29.02.2024
Первое поле 2024-02-30 осталось отклонённым в сохранённом отчёте
Текущая диагностика уже не содержит первого предупреждения

После первого разбора saved получил самостоятельную копию массива предупреждений. Следующий успешный разбор очистил общую диагностику: latest=false в PHP8.2+. Это не изменило saved, поэтому отчёт ещё объясняет отказ первого поля. Сохраняйте диагностику вместе с соответствующим исходным текстом до любого следующего создания или разбора даты.

<?php
$input = '2024-02-30';
$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-02-30
Получено у парсера: 2024-03-01
Не принимаем дату: парсер сообщил о календарном исправлении

GetLastErrors не получает date параметром: он читает состояние последней операции разбора. Возвращённый массив сохранён в issues. У этого входа объект есть и error_count=0, однако предупреждение запрещает использовать его как исходный день. Поэтому проверять только ошибки недостаточно.

<?php
$first = DateTimeImmutable::createFromFormat('!Y-m-d', '2024-02-30', new DateTimeZone('UTC'));
$saved = DateTimeImmutable::getLastErrors();
$second = DateTimeImmutable::createFromFormat('!Y-m-d', '2024-02-29', new DateTimeZone('UTC'));
$latest = DateTimeImmutable::getLastErrors();
if ($second !== false && $latest === false) {
    echo 'Второе поле принято: ', $second->format('d.m.Y'), "\n";
}
if ($saved !== false && $saved['warning_count'] > 0) {
    echo "Первое поле 2024-02-30 осталось отклонённым в сохранённом отчёте\n";
}
if ($latest === false) { echo "Текущая диагностика уже не содержит первого предупреждения\n"; }

Второе поле принято: 29.02.2024
Первое поле 2024-02-30 осталось отклонённым в сохранённом отчёте
Текущая диагностика уже не содержит первого предупреждения

После первого разбора saved получил самостоятельную копию массива предупреждений. Следующий успешный разбор очистил общую диагностику: latest=false в PHP8.2+. Это не изменило saved, поэтому отчёт ещё объясняет отказ первого поля. Сохраняйте диагностику вместе с соответствующим исходным текстом до любого следующего создания или разбора даты.

<?php
$input = '2024-02-30';
$date = DateTimeImmutable::createFromFormat('!Y-m-d', $input, new DateTimeZone('UTC'));
$issues = date_get_last_errors();
echo 'Введено: ', $input, "\n";
if ($date !== false) { echo 'Получено у парсера: ', $date->format('Y-m-d'), "\n"; }
if ($issues !== false && $issues['warning_count'] > 0) {
    echo "Не принимаем дату: парсер сообщил о календарном исправлении\n";
}

Введено: 2024-02-30
Получено у парсера: 2024-03-01
Не принимаем дату: парсер сообщил о календарном исправлении

GetLastErrors не получает date параметром: он читает состояние последней операции разбора. Возвращённый массив сохранён в issues. У этого входа объект есть и error_count=0, однако предупреждение запрещает использовать его как исходный день. Поэтому проверять только ошибки недостаточно.

<?php
$first = DateTimeImmutable::createFromFormat('!Y-m-d', '2024-02-30', new DateTimeZone('UTC'));
$saved = date_get_last_errors();
$second = DateTimeImmutable::createFromFormat('!Y-m-d', '2024-02-29', new DateTimeZone('UTC'));
$latest = date_get_last_errors();
if ($second !== false && $latest === false) {
    echo 'Второе поле принято: ', $second->format('d.m.Y'), "\n";
}
if ($saved !== false && $saved['warning_count'] > 0) {
    echo "Первое поле 2024-02-30 осталось отклонённым в сохранённом отчёте\n";
}
if ($latest === false) { echo "Текущая диагностика уже не содержит первого предупреждения\n"; }

Второе поле принято: 29.02.2024
Первое поле 2024-02-30 осталось отклонённым в сохранённом отчёте
Текущая диагностика уже не содержит первого предупреждения

После первого разбора saved получил самостоятельную копию массива предупреждений. Следующий успешный разбор очистил общую диагностику: latest=false в PHP8.2+. Это не изменило saved, поэтому отчёт ещё объясняет отказ первого поля. Сохраняйте диагностику вместе с соответствующим исходным текстом до любого следующего создания или разбора даты.

<?php
$parts = date_parse('2024-06-15 10:30:00+03:00');
if ($parts['error_count'] > 0 || $parts['warning_count'] > 0) {
    echo "Компоненты не приняты\n";
    return;
}
$reportName = sprintf('events-%04d-%02d-%02d.csv', $parts['year'], $parts['month'], $parts['day']);
echo 'Имя отчёта: ', $reportName, "\n";
echo 'Местные часы события: ', $parts['hour'], ':', $parts['minute'], "\n";
echo 'Смещение: ', $parts['zone'], ' секунд, то есть ', $parts['zone'] / 3600, ' ч', "\n";

Имя отчёта: events-2024-06-15.csv
Местные часы события: 10:30
Смещение: 10800 секунд, то есть 3 ч

Парсер возвращает массив, а не DateTime. У известного входа заполнены year2024/month6/day15/hour10/minute30/zone10800. Sprintf получает шаблон и три числа: %04d пишет год четырьмя цифрами, %02d — месяц и день двумя. Возврат сохраняется в reportName и выводится; файл не создаётся. Смещение поделено на3600 для понятных часов. Для произвольного формата отдельно проверяют наличие нужных компонентов: неизвестное поле может быть false, даже без синтаксической ошибки.

<?php
$parts = date_parse('2024-02-30');
echo 'Парсер выделил месяц ', $parts['month'], ', день ', $parts['day'], "\n";
if ($parts['warning_count'] > 0 || $parts['error_count'] > 0) {
    echo "Отчёт не готовится: исходный день не прошёл проверку\n";
}

Парсер выделил месяц 2, день 30
Отчёт не готовится: исходный день не прошёл проверку

В этом массиве видны исходные2 и30, а не нормализованный мартовский объект. Предупреждение становится причиной остановить подготовку отчёта. Наличие ключей month/day само по себе не подтверждает существование даты. Это удобно для диагностики импортера, но готовый момент с зоной нужно создавать только после проверки договора.

<?php
$text = '2024-06-15 +3 days';
$parts = date_parse($text);
echo 'Базовая запись: ', $parts['year'], '-', $parts['month'], '-', $parts['day'], "\n";
echo 'Относительное правило: плюс ', $parts['relative']['day'], ' дня', "\n";
$resolved = new DateTimeImmutable($text, new DateTimeZone('UTC'));
echo 'Рассчитанный срок: ', $resolved->format('d.m.Y'), "\n";

Базовая запись: 2024-6-15
Относительное правило: плюс 3 дня
Рассчитанный срок: 18.06.2024

Date_parse разделил известную строку на базовые компоненты и вложенный relative, но не заменил day15 итоговым18. Затем конструктор отдельно применил ту же полную строку и вернул объект18 июня. Два разбора здесь намеренны для сравнения API; в прикладном расчёте обычно выбирают нужный результат один раз. Для произвольных relative нельзя учитывать только day: возможны другие поля и правила дней недели.

<?php
$parts = date_parse_from_format('d.m.Y H:iP', '15.06.2024 10:30+03:00');
if ($parts['error_count'] > 0 || $parts['warning_count'] > 0) {
    echo "Компоненты не приняты\n";
    return;
}
$reportName = sprintf('events-%04d-%02d-%02d.csv', $parts['year'], $parts['month'], $parts['day']);
echo 'Имя отчёта: ', $reportName, "\n";
echo 'Местные часы события: ', $parts['hour'], ':', $parts['minute'], "\n";
echo 'Смещение: ', $parts['zone'], ' секунд, то есть ', $parts['zone'] / 3600, ' ч', "\n";

Имя отчёта: events-2024-06-15.csv
Местные часы события: 10:30
Смещение: 10800 секунд, то есть 3 ч

Парсер возвращает массив, а не DateTime. У известного входа заполнены year2024/month6/day15/hour10/minute30/zone10800. Sprintf получает шаблон и три числа: %04d пишет год четырьмя цифрами, %02d — месяц и день двумя. Возврат сохраняется в reportName и выводится; файл не создаётся. Смещение поделено на3600 для понятных часов. Для произвольного формата отдельно проверяют наличие нужных компонентов: неизвестное поле может быть false, даже без синтаксической ошибки.

<?php
$parts = date_parse_from_format('Y-m-d', '2024-02-30');
echo 'Парсер выделил месяц ', $parts['month'], ', день ', $parts['day'], "\n";
if ($parts['warning_count'] > 0 || $parts['error_count'] > 0) {
    echo "Отчёт не готовится: исходный день не прошёл проверку\n";
}

Парсер выделил месяц 2, день 30
Отчёт не готовится: исходный день не прошёл проверку

В этом массиве видны исходные2 и30, а не нормализованный мартовский объект. Предупреждение становится причиной остановить подготовку отчёта. Наличие ключей month/day само по себе не подтверждает существование даты. Это удобно для диагностики импортера, но готовый момент с зоной нужно создавать только после проверки договора.

<?php
declare(strict_types=1);

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

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

Это поведение введено в PHP 8.0.21 / 8.1.8 / 8.2.0. До этих исправлений NULL-байты игнорировались.

<?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 DateTime('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 DateTime('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 DateTime('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 DateTime('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 DateTime('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'));
$label = date_format($date, 'd.m.Y H:i');
echo 'Встреча: ', $label, ' UTC', "\n";
echo 'День для заявки: ', date_format($date, '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($date, 'h:m:s'), "\n";
echo 'Время закрытия H:i:s: ', date_format($date, '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($date, 'o-\WW');
$filename = 'sales-' . $week . '.csv';
echo 'Продажа от: ', date_format($date, 'd.m.Y'), "\n";
echo 'Имя недельного отчёта: ', $filename, "\n";
echo 'Неверная группа Y-W: ', date_format($date, '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($date, DateTimeInterface::RFC3339_EXTENDED);
echo 'EVT-41 для API: ', $apiTime, "\n";
echo 'EVT-41 для журнала: ', date_format($date, '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($date, 'd.m.Y H:i P'), "\n";
$utc = DateTimeImmutable::createFromInterface($date)->setTimezone(new DateTimeZone('UTC'));
$headerValue = date_format($utc, '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
$expires = new DateTimeImmutable('2024-06-15 13:00:00+03:00');
$now = new DateTimeImmutable('2024-06-15 09:45:00+00:00');
$deadlineSeconds = $expires->getTimestamp();
$nowSeconds = $now->getTimestamp();
$remaining = $deadlineSeconds - $nowSeconds;
echo 'Бронь до: ', $expires->format('H:i P'), "\n";
echo 'Проверяем в: ', $now->format('H:i P'), "\n";
echo 'Осталось секунд: ', $remaining, "\n";
echo $remaining > 0 ? "Бронь действует\n" : "Бронь истекла\n";

Бронь до: 13:00 +03:00
Проверяем в: 09:45 +00:00
Осталось секунд: 900
Бронь действует

GetTimestamp возвращает целое число секунд от общего начала Unix. Разность 13:00 +03:00 и 09:45 UTC равна 900 секундам: московский срок означает 10:00 UTC. Смещение уже учтено при создании момента; прибавлять его повторно нельзя. Now здесь зафиксирован ради повторяемости, в рабочем коде его получают из часов или передают параметром. На точной границе remaining=0 бронь по этому правилу уже истекла.

<?php
$event = new DateTimeImmutable('1970-01-01 00:02:03.500000+00:00');
$seconds = $event->getTimestamp();
$millisecondPart = (int) $event->format('v');
$protocolTime = $seconds * 1000 + $millisecondPart;
echo 'Целые секунды события: ', $seconds, "\n";
echo 'Доля в миллисекундах: ', $millisecondPart, "\n";
echo 'Поле event_time_ms: ', $protocolTime, "\n";

Целые секунды события: 123
Доля в миллисекундах: 500
Поле event_time_ms: 123500

Протокол этого опыта требует целое количество миллисекунд. GetTimestamp возвращает 123 без доли; format(v) — строку 500, (int) превращает её в число. Умножение 123 на 1000 и прибавление 500 даёт 123500. Для современных дат такой общий int миллисекунд требует 64-битного PHP; пример специально использует малую положительную метку. Микросекунды точнее миллисекунд и здесь были бы отброшены; отрицательные дробные метки требуют отдельно согласованного правила.

<?php
$expires = new DateTime('2024-06-15 13:00:00+03:00');
$now = new DateTime('2024-06-15 09:45:00+00:00');
$deadlineSeconds = $expires->getTimestamp();
$nowSeconds = $now->getTimestamp();
$remaining = $deadlineSeconds - $nowSeconds;
echo 'Бронь до: ', $expires->format('H:i P'), "\n";
echo 'Проверяем в: ', $now->format('H:i P'), "\n";
echo 'Осталось секунд: ', $remaining, "\n";
echo $remaining > 0 ? "Бронь действует\n" : "Бронь истекла\n";

Бронь до: 13:00 +03:00
Проверяем в: 09:45 +00:00
Осталось секунд: 900
Бронь действует

GetTimestamp возвращает целое число секунд от общего начала Unix. Разность 13:00 +03:00 и 09:45 UTC равна 900 секундам: московский срок означает 10:00 UTC. Смещение уже учтено при создании момента; прибавлять его повторно нельзя. Now здесь зафиксирован ради повторяемости, в рабочем коде его получают из часов или передают параметром. На точной границе remaining=0 бронь по этому правилу уже истекла.

<?php
$event = new DateTime('1970-01-01 00:02:03.500000+00:00');
$seconds = $event->getTimestamp();
$millisecondPart = (int) $event->format('v');
$protocolTime = $seconds * 1000 + $millisecondPart;
echo 'Целые секунды события: ', $seconds, "\n";
echo 'Доля в миллисекундах: ', $millisecondPart, "\n";
echo 'Поле event_time_ms: ', $protocolTime, "\n";

Целые секунды события: 123
Доля в миллисекундах: 500
Поле event_time_ms: 123500

Протокол этого опыта требует целое количество миллисекунд. GetTimestamp возвращает 123 без доли; format(v) — строку 500, (int) превращает её в число. Умножение 123 на 1000 и прибавление 500 даёт 123500. Для современных дат такой общий int миллисекунд требует 64-битного PHP; пример специально использует малую положительную метку. Микросекунды точнее миллисекунд и здесь были бы отброшены; отрицательные дробные метки требуют отдельно согласованного правила.

<?php
$expires = new DateTimeImmutable('2024-06-15 13:00:00+03:00');
$now = new DateTimeImmutable('2024-06-15 09:45:00+00:00');
$deadlineSeconds = $expires->getTimestamp();
$nowSeconds = $now->getTimestamp();
$remaining = $deadlineSeconds - $nowSeconds;
echo 'Бронь до: ', $expires->format('H:i P'), "\n";
echo 'Проверяем в: ', $now->format('H:i P'), "\n";
echo 'Осталось секунд: ', $remaining, "\n";
echo $remaining > 0 ? "Бронь действует\n" : "Бронь истекла\n";

Бронь до: 13:00 +03:00
Проверяем в: 09:45 +00:00
Осталось секунд: 900
Бронь действует

GetTimestamp возвращает целое число секунд от общего начала Unix. Разность 13:00 +03:00 и 09:45 UTC равна 900 секундам: московский срок означает 10:00 UTC. Смещение уже учтено при создании момента; прибавлять его повторно нельзя. Now здесь зафиксирован ради повторяемости, в рабочем коде его получают из часов или передают параметром. На точной границе remaining=0 бронь по этому правилу уже истекла.

<?php
$event = new DateTimeImmutable('1970-01-01 00:02:03.500000+00:00');
$seconds = $event->getTimestamp();
$millisecondPart = (int) $event->format('v');
$protocolTime = $seconds * 1000 + $millisecondPart;
echo 'Целые секунды события: ', $seconds, "\n";
echo 'Доля в миллисекундах: ', $millisecondPart, "\n";
echo 'Поле event_time_ms: ', $protocolTime, "\n";

Целые секунды события: 123
Доля в миллисекундах: 500
Поле event_time_ms: 123500

Протокол этого опыта требует целое количество миллисекунд. GetTimestamp возвращает 123 без доли; format(v) — строку 500, (int) превращает её в число. Умножение 123 на 1000 и прибавление 500 даёт 123500. Для современных дат такой общий int миллисекунд требует 64-битного PHP; пример специально использует малую положительную метку. Микросекунды точнее миллисекунд и здесь были бы отброшены; отрицательные дробные метки требуют отдельно согласованного правила.

<?php
$expires = new DateTimeImmutable('2024-06-15 13:00:00+03:00');
$now = new DateTimeImmutable('2024-06-15 09:45:00+00:00');
$deadlineSeconds = date_timestamp_get($expires);
$nowSeconds = date_timestamp_get($now);
$remaining = $deadlineSeconds - $nowSeconds;
echo 'Бронь до: ', $expires->format('H:i P'), "\n";
echo 'Проверяем в: ', $now->format('H:i P'), "\n";
echo 'Осталось секунд: ', $remaining, "\n";
echo $remaining > 0 ? "Бронь действует\n" : "Бронь истекла\n";

Бронь до: 13:00 +03:00
Проверяем в: 09:45 +00:00
Осталось секунд: 900
Бронь действует

GetTimestamp возвращает целое число секунд от общего начала Unix. Разность 13:00 +03:00 и 09:45 UTC равна 900 секундам: московский срок означает 10:00 UTC. Смещение уже учтено при создании момента; прибавлять его повторно нельзя. Now здесь зафиксирован ради повторяемости, в рабочем коде его получают из часов или передают параметром. На точной границе remaining=0 бронь по этому правилу уже истекла.

<?php
$event = new DateTimeImmutable('1970-01-01 00:02:03.500000+00:00');
$seconds = date_timestamp_get($event);
$millisecondPart = (int) $event->format('v');
$protocolTime = $seconds * 1000 + $millisecondPart;
echo 'Целые секунды события: ', $seconds, "\n";
echo 'Доля в миллисекундах: ', $millisecondPart, "\n";
echo 'Поле event_time_ms: ', $protocolTime, "\n";

Целые секунды события: 123
Доля в миллисекундах: 500
Поле event_time_ms: 123500

Протокол этого опыта требует целое количество миллисекунд. GetTimestamp возвращает 123 без доли; format(v) — строку 500, (int) превращает её в число. Умножение 123 на 1000 и прибавление 500 даёт 123500. Для современных дат такой общий int миллисекунд требует 64-битного PHP; пример специально использует малую положительную метку. Микросекунды точнее миллисекунд и здесь были бы отброшены; отрицательные дробные метки требуют отдельно согласованного правила.

<?php
$winter = new DateTimeImmutable('2024-01-15 10:00:00', new DateTimeZone('Europe/London'));
$summer = new DateTimeImmutable('2024-07-15 10:00:00', new DateTimeZone('Europe/London'));
foreach ([$winter, $summer] as $meeting) {
    $offsetSeconds = $meeting->getOffset();
    $utc = DateTimeImmutable::createFromInterface($meeting)->setTimezone(new DateTimeZone('UTC'));
    echo $meeting->format('d.m.Y H:i'), ' London; смещение ', $offsetSeconds,
        ' с; в UTC ', $utc->format('H:i'), "\n";
}

15.01.2024 10:00 London; смещение 0 с; в UTC 10:00
15.07.2024 10:00 London; смещение 3600 с; в UTC 09:00

Foreach по очереди помещает зимнюю и летнюю дату в meeting. Метод возвращает 0 или 3600 в offsetSeconds для этой даты, а setTimezone отдельно готовит часы участника в UTC. В обеих встречах локально 10:00; летние правила London сместили соответствующий UTC на 09:00. Нельзя однажды записать 3600 вместо Europe/London и ожидать правильное зимнее расписание.

<?php
$received = new DateTimeImmutable('2024-01-15 12:00:00-05:30');
$offsetSeconds = $received->getOffset();
$offsetMinutes = intdiv($offsetSeconds, 60);
$utc = DateTimeImmutable::createFromInterface($received)->setTimezone(new DateTimeZone('UTC'));
echo 'Прислано: ', $received->format('H:i P'), "\n";
echo 'Смещение для карточки события: ', $offsetMinutes, ' минут', "\n";
echo 'Тот же момент UTC: ', $utc->format('H:i'), "\n";

Прислано: 12:00 -05:30
Смещение для карточки события: -330 минут
Тот же момент UTC: 17:30

Метод вернул−19800 секунд. Intdiv делит на 60 и возвращает целую часть: здесь без остатка получилось−330 минут, то есть−5 часов 30 минут. Знак относится ко всему смещению. В исторических зонах бывают смещения с секундами — там такой перевод в целые минуты потеряет остаток. Время в UTC получено сменой представления, а не прибавлением offset к timestamp.

<?php
$winter = new DateTime('2024-01-15 10:00:00', new DateTimeZone('Europe/London'));
$summer = new DateTime('2024-07-15 10:00:00', new DateTimeZone('Europe/London'));
foreach ([$winter, $summer] as $meeting) {
    $offsetSeconds = $meeting->getOffset();
    $utc = DateTimeImmutable::createFromInterface($meeting)->setTimezone(new DateTimeZone('UTC'));
    echo $meeting->format('d.m.Y H:i'), ' London; смещение ', $offsetSeconds,
        ' с; в UTC ', $utc->format('H:i'), "\n";
}

15.01.2024 10:00 London; смещение 0 с; в UTC 10:00
15.07.2024 10:00 London; смещение 3600 с; в UTC 09:00

Foreach по очереди помещает зимнюю и летнюю дату в meeting. Метод возвращает 0 или 3600 в offsetSeconds для этой даты, а setTimezone отдельно готовит часы участника в UTC. В обеих встречах локально 10:00; летние правила London сместили соответствующий UTC на 09:00. Нельзя однажды записать 3600 вместо Europe/London и ожидать правильное зимнее расписание.

<?php
$received = new DateTime('2024-01-15 12:00:00-05:30');
$offsetSeconds = $received->getOffset();
$offsetMinutes = intdiv($offsetSeconds, 60);
$utc = DateTimeImmutable::createFromInterface($received)->setTimezone(new DateTimeZone('UTC'));
echo 'Прислано: ', $received->format('H:i P'), "\n";
echo 'Смещение для карточки события: ', $offsetMinutes, ' минут', "\n";
echo 'Тот же момент UTC: ', $utc->format('H:i'), "\n";

Прислано: 12:00 -05:30
Смещение для карточки события: -330 минут
Тот же момент UTC: 17:30

Метод вернул−19800 секунд. Intdiv делит на 60 и возвращает целую часть: здесь без остатка получилось−330 минут, то есть−5 часов 30 минут. Знак относится ко всему смещению. В исторических зонах бывают смещения с секундами — там такой перевод в целые минуты потеряет остаток. Время в UTC получено сменой представления, а не прибавлением offset к timestamp.

<?php
$winter = new DateTimeImmutable('2024-01-15 10:00:00', new DateTimeZone('Europe/London'));
$summer = new DateTimeImmutable('2024-07-15 10:00:00', new DateTimeZone('Europe/London'));
foreach ([$winter, $summer] as $meeting) {
    $offsetSeconds = $meeting->getOffset();
    $utc = DateTimeImmutable::createFromInterface($meeting)->setTimezone(new DateTimeZone('UTC'));
    echo $meeting->format('d.m.Y H:i'), ' London; смещение ', $offsetSeconds,
        ' с; в UTC ', $utc->format('H:i'), "\n";
}

15.01.2024 10:00 London; смещение 0 с; в UTC 10:00
15.07.2024 10:00 London; смещение 3600 с; в UTC 09:00

Foreach по очереди помещает зимнюю и летнюю дату в meeting. Метод возвращает 0 или 3600 в offsetSeconds для этой даты, а setTimezone отдельно готовит часы участника в UTC. В обеих встречах локально 10:00; летние правила London сместили соответствующий UTC на 09:00. Нельзя однажды записать 3600 вместо Europe/London и ожидать правильное зимнее расписание.

<?php
$received = new DateTimeImmutable('2024-01-15 12:00:00-05:30');
$offsetSeconds = $received->getOffset();
$offsetMinutes = intdiv($offsetSeconds, 60);
$utc = DateTimeImmutable::createFromInterface($received)->setTimezone(new DateTimeZone('UTC'));
echo 'Прислано: ', $received->format('H:i P'), "\n";
echo 'Смещение для карточки события: ', $offsetMinutes, ' минут', "\n";
echo 'Тот же момент UTC: ', $utc->format('H:i'), "\n";

Прислано: 12:00 -05:30
Смещение для карточки события: -330 минут
Тот же момент UTC: 17:30

Метод вернул−19800 секунд. Intdiv делит на 60 и возвращает целую часть: здесь без остатка получилось−330 минут, то есть−5 часов 30 минут. Знак относится ко всему смещению. В исторических зонах бывают смещения с секундами — там такой перевод в целые минуты потеряет остаток. Время в UTC получено сменой представления, а не прибавлением offset к timestamp.

<?php
$winter = new DateTimeImmutable('2024-01-15 10:00:00', new DateTimeZone('Europe/London'));
$summer = new DateTimeImmutable('2024-07-15 10:00:00', new DateTimeZone('Europe/London'));
foreach ([$winter, $summer] as $meeting) {
    $offsetSeconds = date_offset_get($meeting);
    $utc = DateTimeImmutable::createFromInterface($meeting)->setTimezone(new DateTimeZone('UTC'));
    echo $meeting->format('d.m.Y H:i'), ' London; смещение ', $offsetSeconds,
        ' с; в UTC ', $utc->format('H:i'), "\n";
}

15.01.2024 10:00 London; смещение 0 с; в UTC 10:00
15.07.2024 10:00 London; смещение 3600 с; в UTC 09:00

Foreach по очереди помещает зимнюю и летнюю дату в meeting. Метод возвращает 0 или 3600 в offsetSeconds для этой даты, а setTimezone отдельно готовит часы участника в UTC. В обеих встречах локально 10:00; летние правила London сместили соответствующий UTC на 09:00. Нельзя однажды записать 3600 вместо Europe/London и ожидать правильное зимнее расписание.

<?php
$received = new DateTimeImmutable('2024-01-15 12:00:00-05:30');
$offsetSeconds = date_offset_get($received);
$offsetMinutes = intdiv($offsetSeconds, 60);
$utc = DateTimeImmutable::createFromInterface($received)->setTimezone(new DateTimeZone('UTC'));
echo 'Прислано: ', $received->format('H:i P'), "\n";
echo 'Смещение для карточки события: ', $offsetMinutes, ' минут', "\n";
echo 'Тот же момент UTC: ', $utc->format('H:i'), "\n";

Прислано: 12:00 -05:30
Смещение для карточки события: -330 минут
Тот же момент UTC: 17:30

Метод вернул−19800 секунд. Intdiv делит на 60 и возвращает целую часть: здесь без остатка получилось−330 минут, то есть−5 часов 30 минут. Знак относится ко всему смещению. В исторических зонах бывают смещения с секундами — там такой перевод в целые минуты потеряет остаток. Время в UTC получено сменой представления, а не прибавлением offset к timestamp.

<?php
$first = new DateTimeImmutable('2024-01-15 10:00:00', new DateTimeZone('Europe/London'));
$zone = $first->getTimezone();
if ($zone === false) {
    echo "Новая встреча не назначена: зона недоступна\n";
} else {
    $next = new DateTimeImmutable('2024-07-15 10:00:00', $zone);
    echo 'Регион расписания: ', $zone->getName(), "\n";
    echo 'Первая встреча: ', $first->format('d.m.Y H:i P'), "\n";
    echo 'Новая встреча: ', $next->format('d.m.Y H:i P'), "\n";
}

Регион расписания: Europe/London
Первая встреча: 15.01.2024 10:00 +00:00
Новая встреча: 15.07.2024 10:00 +01:00

GetTimezone возвращает объект DateTimeZone в zone. После проверки false передаём именно объект вторым аргументом нового конструктора. Он содержит правила London, поэтому летняя встреча в 10:00 получает+01:00, зимняя сохраняет+00:00. GetName возвращает строку только для подписи. Сама дата из первой встречи в новую не копируется: день и часы заданы новой строкой.

<?php
$received = new DateTimeImmutable('2024-01-15T10:00:00+03:00');
$zone = $received->getTimezone();
if ($zone === false) {
    echo "Нельзя восстановить зону события\n";
} else {
    $next = new DateTimeImmutable('2024-07-15 10:00:00', $zone);
    echo 'В исходных данных известна зона: ', $zone->getName(), "\n";
    echo 'Расписание с этим фиксированным правилом: ', $next->format('d.m.Y H:i P'), "\n";
    echo "Для регионального расписания нужно отдельно получить название региона\n";
}

В исходных данных известна зона: +03:00
Расписание с этим фиксированным правилом: 15.07.2024 10:00 +03:00
Для регионального расписания нужно отдельно получить название региона

Во входной строке нет Europe/Moscow или другого региона, только+03:00. Возвращённый объект сохраняет это фиксированное смещение и летом. GetTimezone не угадывает географию: одинаковое смещение в один день может соответствовать разным региональным правилам. Такое правило подходит, если договор требует именно постоянное+03:00; для местного расписания регион запрашивают отдельно.

<?php
$first = new DateTime('2024-01-15 10:00:00', new DateTimeZone('Europe/London'));
$zone = $first->getTimezone();
if ($zone === false) {
    echo "Новая встреча не назначена: зона недоступна\n";
} else {
    $next = new DateTime('2024-07-15 10:00:00', $zone);
    echo 'Регион расписания: ', $zone->getName(), "\n";
    echo 'Первая встреча: ', $first->format('d.m.Y H:i P'), "\n";
    echo 'Новая встреча: ', $next->format('d.m.Y H:i P'), "\n";
}

Регион расписания: Europe/London
Первая встреча: 15.01.2024 10:00 +00:00
Новая встреча: 15.07.2024 10:00 +01:00

GetTimezone возвращает объект DateTimeZone в zone. После проверки false передаём именно объект вторым аргументом нового конструктора. Он содержит правила London, поэтому летняя встреча в 10:00 получает+01:00, зимняя сохраняет+00:00. GetName возвращает строку только для подписи. Сама дата из первой встречи в новую не копируется: день и часы заданы новой строкой.

<?php
$received = new DateTime('2024-01-15T10:00:00+03:00');
$zone = $received->getTimezone();
if ($zone === false) {
    echo "Нельзя восстановить зону события\n";
} else {
    $next = new DateTime('2024-07-15 10:00:00', $zone);
    echo 'В исходных данных известна зона: ', $zone->getName(), "\n";
    echo 'Расписание с этим фиксированным правилом: ', $next->format('d.m.Y H:i P'), "\n";
    echo "Для регионального расписания нужно отдельно получить название региона\n";
}

В исходных данных известна зона: +03:00
Расписание с этим фиксированным правилом: 15.07.2024 10:00 +03:00
Для регионального расписания нужно отдельно получить название региона

Во входной строке нет Europe/Moscow или другого региона, только+03:00. Возвращённый объект сохраняет это фиксированное смещение и летом. GetTimezone не угадывает географию: одинаковое смещение в один день может соответствовать разным региональным правилам. Такое правило подходит, если договор требует именно постоянное+03:00; для местного расписания регион запрашивают отдельно.

<?php
$first = new DateTimeImmutable('2024-01-15 10:00:00', new DateTimeZone('Europe/London'));
$zone = $first->getTimezone();
if ($zone === false) {
    echo "Новая встреча не назначена: зона недоступна\n";
} else {
    $next = new DateTimeImmutable('2024-07-15 10:00:00', $zone);
    echo 'Регион расписания: ', $zone->getName(), "\n";
    echo 'Первая встреча: ', $first->format('d.m.Y H:i P'), "\n";
    echo 'Новая встреча: ', $next->format('d.m.Y H:i P'), "\n";
}

Регион расписания: Europe/London
Первая встреча: 15.01.2024 10:00 +00:00
Новая встреча: 15.07.2024 10:00 +01:00

GetTimezone возвращает объект DateTimeZone в zone. После проверки false передаём именно объект вторым аргументом нового конструктора. Он содержит правила London, поэтому летняя встреча в 10:00 получает+01:00, зимняя сохраняет+00:00. GetName возвращает строку только для подписи. Сама дата из первой встречи в новую не копируется: день и часы заданы новой строкой.

<?php
$received = new DateTimeImmutable('2024-01-15T10:00:00+03:00');
$zone = $received->getTimezone();
if ($zone === false) {
    echo "Нельзя восстановить зону события\n";
} else {
    $next = new DateTimeImmutable('2024-07-15 10:00:00', $zone);
    echo 'В исходных данных известна зона: ', $zone->getName(), "\n";
    echo 'Расписание с этим фиксированным правилом: ', $next->format('d.m.Y H:i P'), "\n";
    echo "Для регионального расписания нужно отдельно получить название региона\n";
}

В исходных данных известна зона: +03:00
Расписание с этим фиксированным правилом: 15.07.2024 10:00 +03:00
Для регионального расписания нужно отдельно получить название региона

Во входной строке нет Europe/Moscow или другого региона, только+03:00. Возвращённый объект сохраняет это фиксированное смещение и летом. GetTimezone не угадывает географию: одинаковое смещение в один день может соответствовать разным региональным правилам. Такое правило подходит, если договор требует именно постоянное+03:00; для местного расписания регион запрашивают отдельно.

<?php
$first = new DateTimeImmutable('2024-01-15 10:00:00', new DateTimeZone('Europe/London'));
$zone = date_timezone_get($first);
if ($zone === false) {
    echo "Новая встреча не назначена: зона недоступна\n";
} else {
    $next = new DateTimeImmutable('2024-07-15 10:00:00', $zone);
    echo 'Регион расписания: ', $zone->getName(), "\n";
    echo 'Первая встреча: ', $first->format('d.m.Y H:i P'), "\n";
    echo 'Новая встреча: ', $next->format('d.m.Y H:i P'), "\n";
}

Регион расписания: Europe/London
Первая встреча: 15.01.2024 10:00 +00:00
Новая встреча: 15.07.2024 10:00 +01:00

GetTimezone возвращает объект DateTimeZone в zone. После проверки false передаём именно объект вторым аргументом нового конструктора. Он содержит правила London, поэтому летняя встреча в 10:00 получает+01:00, зимняя сохраняет+00:00. GetName возвращает строку только для подписи. Сама дата из первой встречи в новую не копируется: день и часы заданы новой строкой.

<?php
$received = new DateTimeImmutable('2024-01-15T10:00:00+03:00');
$zone = date_timezone_get($received);
if ($zone === false) {
    echo "Нельзя восстановить зону события\n";
} else {
    $next = new DateTimeImmutable('2024-07-15 10:00:00', $zone);
    echo 'В исходных данных известна зона: ', $zone->getName(), "\n";
    echo 'Расписание с этим фиксированным правилом: ', $next->format('d.m.Y H:i P'), "\n";
    echo "Для регионального расписания нужно отдельно получить название региона\n";
}

В исходных данных известна зона: +03:00
Расписание с этим фиксированным правилом: 15.07.2024 10:00 +03:00
Для регионального расписания нужно отдельно получить название региона

Во входной строке нет Europe/Moscow или другого региона, только+03:00. Возвращённый объект сохраняет это фиксированное смещение и летом. GetTimezone не угадывает географию: одинаковое смещение в один день может соответствовать разным региональным правилам. Такое правило подходит, если договор требует именно постоянное+03:00; для местного расписания регион запрашивают отдельно.

<?php
$first = new DateTimeImmutable('2024-01-01 12:34:56.000123', new DateTimeZone('UTC'));
$second = new DateTimeImmutable('2024-01-01 12:34:56.000323', new DateTimeZone('UTC'));
$firstPart = $first->getMicrosecond();
$secondPart = $second->getMicrosecond();
$gap = $secondPart - $firstPart;
echo 'Событие A: ', $first->format('H:i:s.u'), "\n";
echo 'Событие B: ', $second->format('H:i:s.u'), "\n";
echo 'Разница внутри этой секунды: ', $gap, ' мкс', "\n";

Событие A: 12:34:56.000123
Событие B: 12:34:56.000323
Разница внутри этой секунды: 200 мкс

PHP8.4+. Метод вернул числа 123 и 323; их разность 200 микросекунд сохранена в gap и включена в подпись. Format(u) отдельно вывел 000123 и 000323 с ведущими нулями. Вычитание частей допустимо здесь потому, что целая секунда и момент в UTC у событий одинаковы. Для произвольных дат нужно учитывать также целые секунды; иначе переход через границу секунды даст неверную длительность.

<?php
$event = new DateTimeImmutable('2024-01-01 12:34:56', new DateTimeZone('UTC'));
$part = $event->getMicrosecond();
echo 'Событие EVT-42: ', $event->format('H:i:s.u'), "\n";
if ($part === 0) {
    echo "Дробная часть равна нулю; событие принято\n";
} else {
    echo 'Дробная часть события: ', $part, ' мкс', "\n";
}

Событие EVT-42: 12:34:56.000000
Дробная часть равна нулю; событие принято

PHP8.4+. В строке не было дроби, поэтому метод вернул 0 — допустимое число микросекунд. Оно не сообщает об ошибке и само по себе не позволяет узнать, с какой точностью работали исходные часы. Дата передаётся дальше как обычное принятое событие; сведения о точности источника при необходимости хранят отдельно.

<?php
$first = new DateTime('2024-01-01 12:34:56.000123', new DateTimeZone('UTC'));
$second = new DateTime('2024-01-01 12:34:56.000323', new DateTimeZone('UTC'));
$firstPart = $first->getMicrosecond();
$secondPart = $second->getMicrosecond();
$gap = $secondPart - $firstPart;
echo 'Событие A: ', $first->format('H:i:s.u'), "\n";
echo 'Событие B: ', $second->format('H:i:s.u'), "\n";
echo 'Разница внутри этой секунды: ', $gap, ' мкс', "\n";

Событие A: 12:34:56.000123
Событие B: 12:34:56.000323
Разница внутри этой секунды: 200 мкс

PHP8.4+. Метод вернул числа 123 и 323; их разность 200 микросекунд сохранена в gap и включена в подпись. Format(u) отдельно вывел 000123 и 000323 с ведущими нулями. Вычитание частей допустимо здесь потому, что целая секунда и момент в UTC у событий одинаковы. Для произвольных дат нужно учитывать также целые секунды; иначе переход через границу секунды даст неверную длительность.

<?php
$event = new DateTime('2024-01-01 12:34:56', new DateTimeZone('UTC'));
$part = $event->getMicrosecond();
echo 'Событие EVT-42: ', $event->format('H:i:s.u'), "\n";
if ($part === 0) {
    echo "Дробная часть равна нулю; событие принято\n";
} else {
    echo 'Дробная часть события: ', $part, ' мкс', "\n";
}

Событие EVT-42: 12:34:56.000000
Дробная часть равна нулю; событие принято

PHP8.4+. В строке не было дроби, поэтому метод вернул 0 — допустимое число микросекунд. Оно не сообщает об ошибке и само по себе не позволяет узнать, с какой точностью работали исходные часы. Дата передаётся дальше как обычное принятое событие; сведения о точности источника при необходимости хранят отдельно.

<?php
$first = new DateTimeImmutable('2024-01-01 12:34:56.000123', new DateTimeZone('UTC'));
$second = new DateTimeImmutable('2024-01-01 12:34:56.000323', new DateTimeZone('UTC'));
$firstPart = $first->getMicrosecond();
$secondPart = $second->getMicrosecond();
$gap = $secondPart - $firstPart;
echo 'Событие A: ', $first->format('H:i:s.u'), "\n";
echo 'Событие B: ', $second->format('H:i:s.u'), "\n";
echo 'Разница внутри этой секунды: ', $gap, ' мкс', "\n";

Событие A: 12:34:56.000123
Событие B: 12:34:56.000323
Разница внутри этой секунды: 200 мкс

PHP8.4+. Метод вернул числа 123 и 323; их разность 200 микросекунд сохранена в gap и включена в подпись. Format(u) отдельно вывел 000123 и 000323 с ведущими нулями. Вычитание частей допустимо здесь потому, что целая секунда и момент в UTC у событий одинаковы. Для произвольных дат нужно учитывать также целые секунды; иначе переход через границу секунды даст неверную длительность.

<?php
$event = new DateTimeImmutable('2024-01-01 12:34:56', new DateTimeZone('UTC'));
$part = $event->getMicrosecond();
echo 'Событие EVT-42: ', $event->format('H:i:s.u'), "\n";
if ($part === 0) {
    echo "Дробная часть равна нулю; событие принято\n";
} else {
    echo 'Дробная часть события: ', $part, ' мкс', "\n";
}

Событие EVT-42: 12:34:56.000000
Дробная часть равна нулю; событие принято

PHP8.4+. В строке не было дроби, поэтому метод вернул 0 — допустимое число микросекунд. Оно не сообщает об ошибке и само по себе не позволяет узнать, с какой точностью работали исходные часы. Дата передаётся дальше как обычное принятое событие; сведения о точности источника при необходимости хранят отдельно.

<?php
$date = new DateTime('2024-01-15 10:30:00', new DateTimeZone('UTC'));
$next = $date->setDate(2024, 2, 29);
echo 'Новое приглашение: ', $next->format('d.m.Y H:i P'), "\n";
echo 'Исходная переменная после переноса: ', $date->format('d.m.Y H:i'), "\n";

Новое приглашение: 29.02.2024 10:30 +00:00
Исходная переменная после переноса: 29.02.2024 10:30

Аргументы 2024, 2, 29 — год, месяц, день. Они заменили только календарную часть; 10:30 и UTC сохранились. Next передан в format, полученная строка включена в новое приглашение. Вызов меняет сам date и возвращает этот же объект. Дальнейшее чтение date показывает изменённое значение. Присваивание другой переменной не создаёт копию; для неё нужен clone.

<?php
$date = new DateTime('2024-01-15 10:30:00', new DateTimeZone('UTC'));
$year = 2023;
$month = 2;
$day = 29;
$normalized = (clone $date)->setDate($year, $month, $day);
echo 'Без проверки получилось бы: ', $normalized->format('d.m.Y H:i'), "\n";
if (!checkdate($month, $day, $year)) {
    echo 'Перенос отклонён; действующая встреча: ', $date->format('d.m.Y H:i'), "\n";
} else {
    $accepted = $date->setDate($year, $month, $day);
    echo 'Перенос принят: ', $accepted->format('d.m.Y H:i'), "\n";
}

Без проверки получилось бы: 01.03.2023 10:30
Перенос отклонён; действующая встреча: 15.01.2024 10:30

2023 год не високосный: setDate на отдельной копии нормализует 29 февраля в 1 марта. Checkdate принимает другой порядок — месяц, день, год — и возвращает false для исходных частей. Знак ! превращает это в условие отказа. Рабочий date менялся бы только в else, поэтому ошибочный перенос не затронул действующую встречу. Демонстрационную копию normalized не нужно создавать при обычной валидации формы.

<?php
$date = new DateTime('2024-01-15 10:30:00', new DateTimeZone('UTC'));
$next = $date->setDate(2024, 14, 3);
echo 'Внутренние компоненты: год 2024, месяц 14, день 3', "\n";
echo 'Нормализованная дата отчёта: ', $next->format('d.m.Y H:i'), "\n";
if (!checkdate(14, 3, 2024)) {
    echo "Такие компоненты от посетителя нужно отклонить\n";
}

Внутренние компоненты: год 2024, месяц 14, день 3
Нормализованная дата отчёта: 03.02.2025 10:30
Такие компоненты от посетителя нужно отклонить

После двенадцатого месяца счёт продолжается в следующем году: 14 означает февраль 2025. Возвращённая дата может пригодиться внутреннему расчёту, который сознательно допускает перенос. Для поля «месяц» это другое требование: checkdate не принимает 14 как календарный месяц. Нормализация и валидация отвечают на разные вопросы.

<?php
$date = new DateTimeImmutable('2024-01-15 10:30:00', new DateTimeZone('UTC'));
$next = $date->setDate(2024, 2, 29);
echo 'Новое приглашение: ', $next->format('d.m.Y H:i P'), "\n";
echo 'Исходная переменная после переноса: ', $date->format('d.m.Y H:i'), "\n";

Новое приглашение: 29.02.2024 10:30 +00:00
Исходная переменная после переноса: 15.01.2024 10:30

Аргументы 2024, 2, 29 — год, месяц, день. Они заменили только календарную часть; 10:30 и UTC сохранились. Next передан в format, полученная строка включена в новое приглашение. Возвращается новый объект; исходный date сохраняется. Результат нужно присвоить или сразу использовать, иначе выбранная дата потеряется.

<?php
$date = new DateTimeImmutable('2024-01-15 10:30:00', new DateTimeZone('UTC'));
$year = 2023;
$month = 2;
$day = 29;
$normalized = (clone $date)->setDate($year, $month, $day);
echo 'Без проверки получилось бы: ', $normalized->format('d.m.Y H:i'), "\n";
if (!checkdate($month, $day, $year)) {
    echo 'Перенос отклонён; действующая встреча: ', $date->format('d.m.Y H:i'), "\n";
} else {
    $accepted = $date->setDate($year, $month, $day);
    echo 'Перенос принят: ', $accepted->format('d.m.Y H:i'), "\n";
}

Без проверки получилось бы: 01.03.2023 10:30
Перенос отклонён; действующая встреча: 15.01.2024 10:30

2023 год не високосный: setDate на отдельной копии нормализует 29 февраля в 1 марта. Checkdate принимает другой порядок — месяц, день, год — и возвращает false для исходных частей. Знак ! превращает это в условие отказа. Рабочий date менялся бы только в else, поэтому ошибочный перенос не затронул действующую встречу. Демонстрационную копию normalized не нужно создавать при обычной валидации формы.

<?php
$date = new DateTimeImmutable('2024-01-15 10:30:00', new DateTimeZone('UTC'));
$next = $date->setDate(2024, 14, 3);
echo 'Внутренние компоненты: год 2024, месяц 14, день 3', "\n";
echo 'Нормализованная дата отчёта: ', $next->format('d.m.Y H:i'), "\n";
if (!checkdate(14, 3, 2024)) {
    echo "Такие компоненты от посетителя нужно отклонить\n";
}

Внутренние компоненты: год 2024, месяц 14, день 3
Нормализованная дата отчёта: 03.02.2025 10:30
Такие компоненты от посетителя нужно отклонить

После двенадцатого месяца счёт продолжается в следующем году: 14 означает февраль 2025. Возвращённая дата может пригодиться внутреннему расчёту, который сознательно допускает перенос. Для поля «месяц» это другое требование: checkdate не принимает 14 как календарный месяц. Нормализация и валидация отвечают на разные вопросы.

<?php
$date = new DateTime('2024-01-15 10:30:00', new DateTimeZone('UTC'));
$next = date_date_set($date, 2024, 2, 29);
echo 'Новое приглашение: ', $next->format('d.m.Y H:i P'), "\n";
echo 'Исходная переменная после переноса: ', $date->format('d.m.Y H:i'), "\n";

Новое приглашение: 29.02.2024 10:30 +00:00
Исходная переменная после переноса: 29.02.2024 10:30

Аргументы 2024, 2, 29 — год, месяц, день. Они заменили только календарную часть; 10:30 и UTC сохранились. Next передан в format, полученная строка включена в новое приглашение. Вызов меняет сам date и возвращает этот же объект. Дальнейшее чтение date показывает изменённое значение. Присваивание другой переменной не создаёт копию; для неё нужен clone.

<?php
$date = new DateTime('2024-01-15 10:30:00', new DateTimeZone('UTC'));
$year = 2023;
$month = 2;
$day = 29;
$normalized = date_date_set((clone $date), $year, $month, $day);
echo 'Без проверки получилось бы: ', $normalized->format('d.m.Y H:i'), "\n";
if (!checkdate($month, $day, $year)) {
    echo 'Перенос отклонён; действующая встреча: ', $date->format('d.m.Y H:i'), "\n";
} else {
    $accepted = date_date_set($date, $year, $month, $day);
    echo 'Перенос принят: ', $accepted->format('d.m.Y H:i'), "\n";
}

Без проверки получилось бы: 01.03.2023 10:30
Перенос отклонён; действующая встреча: 15.01.2024 10:30

2023 год не високосный: setDate на отдельной копии нормализует 29 февраля в 1 марта. Checkdate принимает другой порядок — месяц, день, год — и возвращает false для исходных частей. Знак ! превращает это в условие отказа. Рабочий date менялся бы только в else, поэтому ошибочный перенос не затронул действующую встречу. Демонстрационную копию normalized не нужно создавать при обычной валидации формы.

<?php
$date = new DateTime('2024-01-15 10:30:00', new DateTimeZone('UTC'));
$next = date_date_set($date, 2024, 14, 3);
echo 'Внутренние компоненты: год 2024, месяц 14, день 3', "\n";
echo 'Нормализованная дата отчёта: ', $next->format('d.m.Y H:i'), "\n";
if (!checkdate(14, 3, 2024)) {
    echo "Такие компоненты от посетителя нужно отклонить\n";
}

Внутренние компоненты: год 2024, месяц 14, день 3
Нормализованная дата отчёта: 03.02.2025 10:30
Такие компоненты от посетителя нужно отклонить

После двенадцатого месяца счёт продолжается в следующем году: 14 означает февраль 2025. Возвращённая дата может пригодиться внутреннему расчёту, который сознательно допускает перенос. Для поля «месяц» это другое требование: checkdate не принимает 14 как календарный месяц. Нормализация и валидация отвечают на разные вопросы.

<?php
$date = new DateTime('2024-06-15 10:30:00', new DateTimeZone('UTC'));
$monday = $date->setISODate(2025, 1);
echo 'Понедельник после выбора недели: ', $monday->format('d.m.Y H:i'), "\n";
$start = $monday->setTime(0, 0);
echo 'Отчётная неделя: ', $start->format('o-\WW'), "\n";
echo 'Начало отбора событий: ', $start->format('d.m.Y H:i P'), "\n";

Понедельник после выбора недели: 30.12.2024 10:30
Отчётная неделя: 2025-W01
Начало отбора событий: 30.12.2024 00:00 +00:00

Первый аргумент — ISO-год 2025, второй — неделя 1. Третий не указан, поэтому dayOfWeek=1 выбирает понедельник. Он приходится на 30 декабря календарного 2024 года. SetISODate сохранил 10:30; отдельный setTime(0,0) задаёт полночь для границы отчёта. В format o связан с W, а обратный слеш перед первой W выводит буквальную букву. Вызов меняет сам date и возвращает этот же объект. Дальнейшее чтение date показывает изменённое значение. Присваивание другой переменной не создаёт копию; для неё нужен clone.

<?php
$date = new DateTime('2024-06-15 00:00:00', new DateTimeZone('UTC'));
$sunday = (clone $date)->setISODate(2025, 1, 7);
$nextMonday = (clone $date)->setISODate(2025, 1, 8);
echo 'Последний день недели: ', $sunday->format('d.m.Y'), "\n";
echo 'День 8, уже следующая неделя: ', $nextMonday->format('d.m.Y'), "\n";

Последний день недели: 05.01.2025
День 8, уже следующая неделя: 06.01.2025

7 выбирает воскресенье той же недели, 8 нормализуется в следующий понедельник. Копии делают два расчёта независимыми и для изменяемого DateTime. Для выбора дня недели посетителем ограничивайте ввод 1…7; нормализация не заменяет эту проверку. Для отбора событий удобна правая исключённая граница следующего понедельника, чтобы включить весь последний день.

<?php
$year = 2021;
$week = 53;
$base = new DateTime('2024-06-15 00:00:00', new DateTimeZone('UTC'));
$candidate = $base->setISODate($year, $week);
$requested = sprintf('%04d-%02d', $year, $week);
echo 'Запрошена ISO-неделя: ', $requested, "\n";
echo 'Метод построил: ', $candidate->format('o-W'), ' с ', $candidate->format('d.m.Y'), "\n";
if ($candidate->format('o-W') !== $requested) {
    echo "Отчёт не построен: в этом ISO-году нет такой недели\n";
}

Запрошена ISO-неделя: 2021-53
Метод построил: 2022-01 с 03.01.2022
Отчёт не построен: в этом ISO-году нет такой недели

Диапазон 1…53 необходим, но недостаточен: не каждый ISO-год имеет неделю 53. Sprintf строит ожидаемую строку с четырьмя цифрами года и двумя номера недели. Обратный format(o-W) выявляет нормализацию в 2022-01, поэтому программа не строит отчёт по другой неделе. Для произвольного ввода сначала отдельно проверяют допустимые для сервиса годы и числовые диапазоны.

<?php
$date = new DateTimeImmutable('2024-06-15 10:30:00', new DateTimeZone('UTC'));
$monday = $date->setISODate(2025, 1);
echo 'Понедельник после выбора недели: ', $monday->format('d.m.Y H:i'), "\n";
$start = $monday->setTime(0, 0);
echo 'Отчётная неделя: ', $start->format('o-\WW'), "\n";
echo 'Начало отбора событий: ', $start->format('d.m.Y H:i P'), "\n";

Понедельник после выбора недели: 30.12.2024 10:30
Отчётная неделя: 2025-W01
Начало отбора событий: 30.12.2024 00:00 +00:00

Первый аргумент — ISO-год 2025, второй — неделя 1. Третий не указан, поэтому dayOfWeek=1 выбирает понедельник. Он приходится на 30 декабря календарного 2024 года. SetISODate сохранил 10:30; отдельный setTime(0,0) задаёт полночь для границы отчёта. В format o связан с W, а обратный слеш перед первой W выводит буквальную букву. Возвращается новый объект; исходный date сохраняется. Результат нужно присвоить или сразу использовать, иначе выбранная дата потеряется.

<?php
$date = new DateTimeImmutable('2024-06-15 00:00:00', new DateTimeZone('UTC'));
$sunday = (clone $date)->setISODate(2025, 1, 7);
$nextMonday = (clone $date)->setISODate(2025, 1, 8);
echo 'Последний день недели: ', $sunday->format('d.m.Y'), "\n";
echo 'День 8, уже следующая неделя: ', $nextMonday->format('d.m.Y'), "\n";

Последний день недели: 05.01.2025
День 8, уже следующая неделя: 06.01.2025

7 выбирает воскресенье той же недели, 8 нормализуется в следующий понедельник. Копии делают два расчёта независимыми и для изменяемого DateTime. Для выбора дня недели посетителем ограничивайте ввод 1…7; нормализация не заменяет эту проверку. Для отбора событий удобна правая исключённая граница следующего понедельника, чтобы включить весь последний день.

<?php
$year = 2021;
$week = 53;
$base = new DateTimeImmutable('2024-06-15 00:00:00', new DateTimeZone('UTC'));
$candidate = $base->setISODate($year, $week);
$requested = sprintf('%04d-%02d', $year, $week);
echo 'Запрошена ISO-неделя: ', $requested, "\n";
echo 'Метод построил: ', $candidate->format('o-W'), ' с ', $candidate->format('d.m.Y'), "\n";
if ($candidate->format('o-W') !== $requested) {
    echo "Отчёт не построен: в этом ISO-году нет такой недели\n";
}

Запрошена ISO-неделя: 2021-53
Метод построил: 2022-01 с 03.01.2022
Отчёт не построен: в этом ISO-году нет такой недели

Диапазон 1…53 необходим, но недостаточен: не каждый ISO-год имеет неделю 53. Sprintf строит ожидаемую строку с четырьмя цифрами года и двумя номера недели. Обратный format(o-W) выявляет нормализацию в 2022-01, поэтому программа не строит отчёт по другой неделе. Для произвольного ввода сначала отдельно проверяют допустимые для сервиса годы и числовые диапазоны.

<?php
$date = new DateTime('2024-06-15 10:30:00', new DateTimeZone('UTC'));
$monday = date_isodate_set($date, 2025, 1);
echo 'Понедельник после выбора недели: ', $monday->format('d.m.Y H:i'), "\n";
$start = $monday->setTime(0, 0);
echo 'Отчётная неделя: ', $start->format('o-\WW'), "\n";
echo 'Начало отбора событий: ', $start->format('d.m.Y H:i P'), "\n";

Понедельник после выбора недели: 30.12.2024 10:30
Отчётная неделя: 2025-W01
Начало отбора событий: 30.12.2024 00:00 +00:00

Первый аргумент — ISO-год 2025, второй — неделя 1. Третий не указан, поэтому dayOfWeek=1 выбирает понедельник. Он приходится на 30 декабря календарного 2024 года. SetISODate сохранил 10:30; отдельный setTime(0,0) задаёт полночь для границы отчёта. В format o связан с W, а обратный слеш перед первой W выводит буквальную букву. Вызов меняет сам date и возвращает этот же объект. Дальнейшее чтение date показывает изменённое значение. Присваивание другой переменной не создаёт копию; для неё нужен clone.

<?php
$date = new DateTime('2024-06-15 00:00:00', new DateTimeZone('UTC'));
$sunday = date_isodate_set((clone $date), 2025, 1, 7);
$nextMonday = date_isodate_set((clone $date), 2025, 1, 8);
echo 'Последний день недели: ', $sunday->format('d.m.Y'), "\n";
echo 'День 8, уже следующая неделя: ', $nextMonday->format('d.m.Y'), "\n";

Последний день недели: 05.01.2025
День 8, уже следующая неделя: 06.01.2025

7 выбирает воскресенье той же недели, 8 нормализуется в следующий понедельник. Копии делают два расчёта независимыми и для изменяемого DateTime. Для выбора дня недели посетителем ограничивайте ввод 1…7; нормализация не заменяет эту проверку. Для отбора событий удобна правая исключённая граница следующего понедельника, чтобы включить весь последний день.

<?php
$year = 2021;
$week = 53;
$base = new DateTime('2024-06-15 00:00:00', new DateTimeZone('UTC'));
$candidate = date_isodate_set($base, $year, $week);
$requested = sprintf('%04d-%02d', $year, $week);
echo 'Запрошена ISO-неделя: ', $requested, "\n";
echo 'Метод построил: ', $candidate->format('o-W'), ' с ', $candidate->format('d.m.Y'), "\n";
if ($candidate->format('o-W') !== $requested) {
    echo "Отчёт не построен: в этом ISO-году нет такой недели\n";
}

Запрошена ISO-неделя: 2021-53
Метод построил: 2022-01 с 03.01.2022
Отчёт не построен: в этом ISO-году нет такой недели

Диапазон 1…53 необходим, но недостаточен: не каждый ISO-год имеет неделю 53. Sprintf строит ожидаемую строку с четырьмя цифрами года и двумя номера недели. Обратный format(o-W) выявляет нормализацию в 2022-01, поэтому программа не строит отчёт по другой неделе. Для произвольного ввода сначала отдельно проверяют допустимые для сервиса годы и числовые диапазоны.

<?php
$date = new DateTime('2024-06-15 10:30:45.123456', new DateTimeZone('UTC'));
$next = $date->setTime(14, 20);
echo 'Звонок назначен: ', $next->format('d.m.Y H:i:s.u P'), "\n";
echo 'Исходная переменная: ', $date->format('H:i:s.u'), "\n";

Звонок назначен: 15.06.2024 14:20:00.000000 +00:00
Исходная переменная: 14:20:00.000000

14 и 20 попали в параметры hour/minute. Second и microsecond пропущены и получают 0, поэтому прежние 45.123456 секунды не остались в сроке. День и зона сохранены. Next форматируется в подтверждение звонка. Вызов меняет сам date и возвращает этот же объект. Дальнейшее чтение date показывает изменённое значение. Присваивание другой переменной не создаёт копию; для неё нужен clone.

<?php
$date = new DateTime('2024-06-15 10:30:00', new DateTimeZone('UTC'));
$normalized = (clone $date)->setTime(25, 0, 65, 125000);
echo 'Получено из компонентов 25:00:65 и 125000 мкс: ', $normalized->format('d.m.Y H:i:s.u'), "\n";
$hour = 25;
if ($hour < 0 || $hour > 23) {
    echo 'Часы формы отклонены; прежняя встреча: ', $date->format('d.m.Y H:i'), "\n";
}

Получено из компонентов 25:00:65 и 125000 мкс: 16.06.2024 01:01:05.125000
Часы формы отклонены; прежняя встреча: 15.06.2024 10:30

25 часов превращаются в следующий день и 1 час; 65 секунд — в 1 минуту и 5 секунд. Доля 125000 микросекунд остаётся 0.125000 секунды. Для демонстрации использована копия, затем показана отдельная проверка часа формы. В полном вводе так же проверяют минуты/секунды 0…59 и микросекунды 0…999999 до вызова; нормализация допустима только по правилу вашей задачи.

<?php
$zone = new DateTimeZone('America/New_York');
$date = new DateTime('2024-11-03 00:00:00', $zone);
$early = $date->setTime(1, 30);
$lateInput = new DateTimeImmutable('2024-11-03T01:30:00-05:00');
$late = $lateInput->setTimezone($zone);
echo 'Первое вхождение 01:30: ', $early->format('d.m.Y H:i P'), "\n";
echo 'Второе, выбранное явно: ', $late->format('d.m.Y H:i P'), "\n";
echo 'Между встречами секунд: ', $late->getTimestamp() - $early->getTimestamp(), "\n";

Первое вхождение 01:30: 03.11.2024 01:30 -04:00
Второе, выбранное явно: 03.11.2024 01:30 -05:00
Между встречами секунд: 3600

В эту ночь часы переводят назад, поэтому 01:30 наступает дважды. С PHP8.1 setTime выбирает раннее вхождение со смещением −04:00; старые версии выбирали позднее. Строка lateInput явно задаёт −05:00, после чего зона New York сохраняет выбранный момент. Одинаковая подпись без смещения скрывала бы разницу в час. При бронировании нужно согласовать выбор с пользователем, а не молча считать обе строки одной встречей.

<?php
$date = new DateTimeImmutable('2024-06-15 10:30:45.123456', new DateTimeZone('UTC'));
$next = $date->setTime(14, 20);
echo 'Звонок назначен: ', $next->format('d.m.Y H:i:s.u P'), "\n";
echo 'Исходная переменная: ', $date->format('H:i:s.u'), "\n";

Звонок назначен: 15.06.2024 14:20:00.000000 +00:00
Исходная переменная: 10:30:45.123456

14 и 20 попали в параметры hour/minute. Second и microsecond пропущены и получают 0, поэтому прежние 45.123456 секунды не остались в сроке. День и зона сохранены. Next форматируется в подтверждение звонка. Возвращается новый объект; исходный date сохраняется. Результат нужно присвоить или сразу использовать, иначе выбранная дата потеряется.

<?php
$date = new DateTimeImmutable('2024-06-15 10:30:00', new DateTimeZone('UTC'));
$normalized = (clone $date)->setTime(25, 0, 65, 125000);
echo 'Получено из компонентов 25:00:65 и 125000 мкс: ', $normalized->format('d.m.Y H:i:s.u'), "\n";
$hour = 25;
if ($hour < 0 || $hour > 23) {
    echo 'Часы формы отклонены; прежняя встреча: ', $date->format('d.m.Y H:i'), "\n";
}

Получено из компонентов 25:00:65 и 125000 мкс: 16.06.2024 01:01:05.125000
Часы формы отклонены; прежняя встреча: 15.06.2024 10:30

25 часов превращаются в следующий день и 1 час; 65 секунд — в 1 минуту и 5 секунд. Доля 125000 микросекунд остаётся 0.125000 секунды. Для демонстрации использована копия, затем показана отдельная проверка часа формы. В полном вводе так же проверяют минуты/секунды 0…59 и микросекунды 0…999999 до вызова; нормализация допустима только по правилу вашей задачи.

<?php
$zone = new DateTimeZone('America/New_York');
$date = new DateTimeImmutable('2024-11-03 00:00:00', $zone);
$early = $date->setTime(1, 30);
$lateInput = new DateTimeImmutable('2024-11-03T01:30:00-05:00');
$late = $lateInput->setTimezone($zone);
echo 'Первое вхождение 01:30: ', $early->format('d.m.Y H:i P'), "\n";
echo 'Второе, выбранное явно: ', $late->format('d.m.Y H:i P'), "\n";
echo 'Между встречами секунд: ', $late->getTimestamp() - $early->getTimestamp(), "\n";

Первое вхождение 01:30: 03.11.2024 01:30 -04:00
Второе, выбранное явно: 03.11.2024 01:30 -05:00
Между встречами секунд: 3600

В эту ночь часы переводят назад, поэтому 01:30 наступает дважды. С PHP8.1 setTime выбирает раннее вхождение со смещением −04:00; старые версии выбирали позднее. Строка lateInput явно задаёт −05:00, после чего зона New York сохраняет выбранный момент. Одинаковая подпись без смещения скрывала бы разницу в час. При бронировании нужно согласовать выбор с пользователем, а не молча считать обе строки одной встречей.

<?php
$date = new DateTime('2024-06-15 10:30:45.123456', new DateTimeZone('UTC'));
$next = date_time_set($date, 14, 20);
echo 'Звонок назначен: ', $next->format('d.m.Y H:i:s.u P'), "\n";
echo 'Исходная переменная: ', $date->format('H:i:s.u'), "\n";

Звонок назначен: 15.06.2024 14:20:00.000000 +00:00
Исходная переменная: 14:20:00.000000

14 и 20 попали в параметры hour/minute. Second и microsecond пропущены и получают 0, поэтому прежние 45.123456 секунды не остались в сроке. День и зона сохранены. Next форматируется в подтверждение звонка. Вызов меняет сам date и возвращает этот же объект. Дальнейшее чтение date показывает изменённое значение. Присваивание другой переменной не создаёт копию; для неё нужен clone.

<?php
$date = new DateTime('2024-06-15 10:30:00', new DateTimeZone('UTC'));
$normalized = date_time_set((clone $date), 25, 0, 65, 125000);
echo 'Получено из компонентов 25:00:65 и 125000 мкс: ', $normalized->format('d.m.Y H:i:s.u'), "\n";
$hour = 25;
if ($hour < 0 || $hour > 23) {
    echo 'Часы формы отклонены; прежняя встреча: ', $date->format('d.m.Y H:i'), "\n";
}

Получено из компонентов 25:00:65 и 125000 мкс: 16.06.2024 01:01:05.125000
Часы формы отклонены; прежняя встреча: 15.06.2024 10:30

25 часов превращаются в следующий день и 1 час; 65 секунд — в 1 минуту и 5 секунд. Доля 125000 микросекунд остаётся 0.125000 секунды. Для демонстрации использована копия, затем показана отдельная проверка часа формы. В полном вводе так же проверяют минуты/секунды 0…59 и микросекунды 0…999999 до вызова; нормализация допустима только по правилу вашей задачи.

<?php
$zone = new DateTimeZone('America/New_York');
$date = new DateTime('2024-11-03 00:00:00', $zone);
$early = date_time_set($date, 1, 30);
$lateInput = new DateTimeImmutable('2024-11-03T01:30:00-05:00');
$late = $lateInput->setTimezone($zone);
echo 'Первое вхождение 01:30: ', $early->format('d.m.Y H:i P'), "\n";
echo 'Второе, выбранное явно: ', $late->format('d.m.Y H:i P'), "\n";
echo 'Между встречами секунд: ', $late->getTimestamp() - $early->getTimestamp(), "\n";

Первое вхождение 01:30: 03.11.2024 01:30 -04:00
Второе, выбранное явно: 03.11.2024 01:30 -05:00
Между встречами секунд: 3600

В эту ночь часы переводят назад, поэтому 01:30 наступает дважды. С PHP8.1 setTime выбирает раннее вхождение со смещением −04:00; старые версии выбирали позднее. Строка lateInput явно задаёт −05:00, после чего зона New York сохраняет выбранный момент. Одинаковая подпись без смещения скрывала бы разницу в час. При бронировании нужно согласовать выбор с пользователем, а не молча считать обе строки одной встречей.

<?php
$timestamp = 1704067200;
$date = new DateTime('2024-06-15 10:30:00.125456', new DateTimeZone('Europe/Moscow'));
$next = $date->setTimestamp($timestamp);
echo 'Событие EVT-41: ', $next->format('d.m.Y H:i:s.u P'), "\n";
echo 'Зона журнала: ', $next->getTimezone()->getName(), "\n";

Событие EVT-41: 01.01.2024 03:00:00.000000 +03:00
Зона журнала: Europe/Moscow

1704067200 означает полночь 1 января 2024 UTC. SetTimestamp заменил момент, оставив Europe/Moscow, поэтому подпись показывает 03:00. Переданы целые секунды — прежняя дробь 125456 обнулилась. Next используется для строки события; getTimezone/getName показывают сохранённое правило отображения. Вызов меняет сам date и возвращает этот же объект. Дальнейшее чтение date показывает изменённое значение. Присваивание другой переменной не создаёт копию; для неё нужен clone.

<?php
$milliseconds = 1500;
$seconds = intdiv($milliseconds, 1000);
$discarded = $milliseconds % 1000;
$date = new DateTime('2024-06-15 00:00:00', new DateTimeZone('UTC'));
$next = $date->setTimestamp($seconds);
echo 'Получено: ', $milliseconds, ' мс после начала Unix', "\n";
echo 'В журнале с точностью до секунды: ', $next->format('Y-m-d H:i:s.u'), "\n";
echo 'Отброшенная доля: ', $discarded, ' мс', "\n";

Получено: 1500 мс после начала Unix
В журнале с точностью до секунды: 1970-01-01 00:00:01.000000
Отброшенная доля: 500 мс

Intdiv(1500,1000) возвращает 1 целую секунду, % даёт остаток 500. SetTimestamp получает 1, а не 1500; строка результата честно показывает нулевую долю. Пример намеренно допускает потерю доли. Если договор требует миллисекунды, используйте дробную createFromTimestamp в PHP8.4+ или восстановите дробную часть отдельно. Этот простой расчёт ограничен неотрицательным вводом: для моментов до epoch нужно отдельно выбрать правила деления и остатка.

<?php
$timestamp = 1704067200;
$date = new DateTimeImmutable('2024-06-15 10:30:00.125456', new DateTimeZone('Europe/Moscow'));
$next = $date->setTimestamp($timestamp);
echo 'Событие EVT-41: ', $next->format('d.m.Y H:i:s.u P'), "\n";
echo 'Зона журнала: ', $next->getTimezone()->getName(), "\n";

Событие EVT-41: 01.01.2024 03:00:00.000000 +03:00
Зона журнала: Europe/Moscow

1704067200 означает полночь 1 января 2024 UTC. SetTimestamp заменил момент, оставив Europe/Moscow, поэтому подпись показывает 03:00. Переданы целые секунды — прежняя дробь 125456 обнулилась. Next используется для строки события; getTimezone/getName показывают сохранённое правило отображения. Возвращается новый объект; исходный date сохраняется. Результат нужно присвоить или сразу использовать, иначе выбранная дата потеряется.

<?php
$milliseconds = 1500;
$seconds = intdiv($milliseconds, 1000);
$discarded = $milliseconds % 1000;
$date = new DateTimeImmutable('2024-06-15 00:00:00', new DateTimeZone('UTC'));
$next = $date->setTimestamp($seconds);
echo 'Получено: ', $milliseconds, ' мс после начала Unix', "\n";
echo 'В журнале с точностью до секунды: ', $next->format('Y-m-d H:i:s.u'), "\n";
echo 'Отброшенная доля: ', $discarded, ' мс', "\n";

Получено: 1500 мс после начала Unix
В журнале с точностью до секунды: 1970-01-01 00:00:01.000000
Отброшенная доля: 500 мс

Intdiv(1500,1000) возвращает 1 целую секунду, % даёт остаток 500. SetTimestamp получает 1, а не 1500; строка результата честно показывает нулевую долю. Пример намеренно допускает потерю доли. Если договор требует миллисекунды, используйте дробную createFromTimestamp в PHP8.4+ или восстановите дробную часть отдельно. Этот простой расчёт ограничен неотрицательным вводом: для моментов до epoch нужно отдельно выбрать правила деления и остатка.

<?php
$timestamp = 1704067200;
$date = new DateTime('2024-06-15 10:30:00.125456', new DateTimeZone('Europe/Moscow'));
$next = date_timestamp_set($date, $timestamp);
echo 'Событие EVT-41: ', $next->format('d.m.Y H:i:s.u P'), "\n";
echo 'Зона журнала: ', $next->getTimezone()->getName(), "\n";

Событие EVT-41: 01.01.2024 03:00:00.000000 +03:00
Зона журнала: Europe/Moscow

1704067200 означает полночь 1 января 2024 UTC. SetTimestamp заменил момент, оставив Europe/Moscow, поэтому подпись показывает 03:00. Переданы целые секунды — прежняя дробь 125456 обнулилась. Next используется для строки события; getTimezone/getName показывают сохранённое правило отображения. Вызов меняет сам date и возвращает этот же объект. Дальнейшее чтение date показывает изменённое значение. Присваивание другой переменной не создаёт копию; для неё нужен clone.

<?php
$milliseconds = 1500;
$seconds = intdiv($milliseconds, 1000);
$discarded = $milliseconds % 1000;
$date = new DateTime('2024-06-15 00:00:00', new DateTimeZone('UTC'));
$next = date_timestamp_set($date, $seconds);
echo 'Получено: ', $milliseconds, ' мс после начала Unix', "\n";
echo 'В журнале с точностью до секунды: ', $next->format('Y-m-d H:i:s.u'), "\n";
echo 'Отброшенная доля: ', $discarded, ' мс', "\n";

Получено: 1500 мс после начала Unix
В журнале с точностью до секунды: 1970-01-01 00:00:01.000000
Отброшенная доля: 500 мс

Intdiv(1500,1000) возвращает 1 целую секунду, % даёт остаток 500. SetTimestamp получает 1, а не 1500; строка результата честно показывает нулевую долю. Пример намеренно допускает потерю доли. Если договор требует миллисекунды, используйте дробную createFromTimestamp в PHP8.4+ или восстановите дробную часть отдельно. Этот простой расчёт ограничен неотрицательным вводом: для моментов до epoch нужно отдельно выбрать правила деления и остатка.