Метод toRFC2822

RFC 2822 — формат представления даты и времени, широко используемый в электронных письмах и HTTP-заголовках. В Luxon преобразование объекта DateTime в строку этого формата выполняется методом toRFC2822(). Результат всегда соответствует спецификации и включает день недели, число месяца, сокращённое название месяца, год, время и смещение часового пояса.

Строка формируется по шаблону:

Day, DD Mon YYYY HH:mm:ss ±ZZZZ

Пример:

Mon, 05 Feb 2024 14:30:00 +0300

Ключевые элементы:

  • день недели в сокращённой английской форме
  • число месяца с ведущим нулём
  • сокращённое название месяца
  • четырёхзначный год
  • время в 24-часовом формате
  • смещение относительно UTC без двоеточия

Использование toRFC2822 в Luxon

Метод вызывается у экземпляра DateTime и возвращает строку без дополнительных параметров.

import { DateTime } from "luxon";

const dt = DateTime.local(2024, 2, 5, 14, 30);
const rfc = dt.toRFC2822();

console.log(rfc);

Результат зависит от локальной временной зоны окружения:

Mon, 05 Feb 2024 14:30:00 +0300

Влияние временной зоны

Luxon учитывает текущую временную зону объекта DateTime. Это означает, что один и тот же момент времени может быть представлен с разными смещениями.

const dt1 = DateTime.fromISO("2024-02-05T14:30:00", { zone: "utc" });
const dt2 = dt1.setZone("Europe/Moscow");

console.log(dt1.toRFC2822());
console.log(dt2.toRFC2822());

Вывод:

Mon, 05 Feb 2024 14:30:00 +0000
Mon, 05 Feb 2024 17:30:00 +0300

Формат сохраняет реальное локальное время относительно указанной зоны.

Отличие от toISO и toHTTP

Метод toRFC2822() не является универсальным форматом сериализации. Его поведение отличается от других методов Luxon:

  • toISO() — машинно-ориентированный формат ISO 8601, используемый в API и базах данных
  • toHTTP() — формат HTTP-заголовков, похожий, но всегда в UTC
  • toRFC2822() — человекочитаемый формат для почтовых систем и некоторых сетевых протоколов
const dt = DateTime.local(2024, 2, 5, 14, 30);

dt.toISO();
dt.toHTTP();
dt.toRFC2822();

Разница заключается не только в формате строки, но и в том, как учитывается временная зона.

Особенности форматирования

Метод строго следует спецификации RFC 2822:

  • день недели всегда на английском языке
  • месяц всегда сокращённый английский
  • отсутствие локализации влияет только на представление, но не на расчёт времени
  • смещение всегда в формате ±HHMM, без двоеточий

Даже при изменении локали Luxon не изменяет язык вывода:

const dt = DateTime.local(2024, 2, 5).setLocale("ru");

console.log(dt.toRFC2822());

Результат остаётся англоязычным:

Mon, 05 Feb 2024 00:00:00 +0300

Работа с UTC

При переводе времени в UTC формат корректно обновляет смещение:

const dt = DateTime.local(2024, 2, 5, 14, 30).toUTC();

console.log(dt.toRFC2822());

Вывод:

Mon, 05 Feb 2024 14:30:00 +0000

Это важно при формировании заголовков для сетевых протоколов, где требуется единая временная база.

Граничные случаи

При работе с некорректными или частично заданными датами поведение зависит от состояния объекта DateTime:

  • если дата валидна — возвращается корректная RFC 2822 строка
  • если объект невалиден — возвращается строка "Invalid DateTime"
const dt = DateTime.fromObject({ year: 2024, month: 2 });

console.log(dt.toRFC2822());

Если не хватает компонентов времени, Luxon подставляет стандартные значения (00:00:00).

Сравнение с ручным форматированием

Без Luxon RFC 2822 приходится собирать вручную:

const date = new Date();

const result =
  date.toUTCString().replace("GMT", "+0000");

Такой подход требует дополнительной обработки и не гарантирует полного соответствия спецификации. Luxon решает это напрямую через toRFC2822().

Поведение при изменении объекта

Метод не изменяет исходный объект DateTime. Он всегда возвращает новую строку, оставляя экземпляр неизменным.

const dt = DateTime.local(2024, 2, 5);
const formatted = dt.toRFC2822();

console.log(dt.isValid); // true
console.log(typeof formatted); // string

Использование в протоколах

Формат RFC 2822 применяется в:

  • заголовках электронной почты (Date header)
  • некоторых HTTP-ответах
  • устаревших, но совместимых API
  • логировании событий с временными метками

Строгое соответствие формату важно для совместимости между системами, где парсинг выполняется по фиксированному шаблону.

Оглавление