Settings.defaultLocale

В библиотеке Luxon локаль определяет правила форматирования дат и времени: названия месяцев, дней недели, формат чисел, порядок элементов даты, особенности отображения времени. В основе лежит стандарт Internationalization API (Intl), поэтому поведение тесно связано с поддержкой локалей в среде выполнения JavaScript.

Локаль может задаваться на разных уровнях, и именно порядок приоритетов делает систему гибкой:

  1. Локаль конкретного объекта DateTime
  2. Глобальная локаль через Settings.defaultLocale
  3. Локаль среды выполнения (browser / Node.js)

Settings как центральный механизм конфигурации

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

Он находится в модуле luxon и содержит параметры, которые действуют как значения по умолчанию:

  • defaultZone
  • defaultLocale
  • defaultOutputCalendar
  • throwOnInvalid

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

Settings.defaultLocale и его роль

Settings.defaultLocale определяет локаль, которая будет применяться ко всем объектам DateTime, если локаль не задана явно.

С точки зрения механики:

  • если у DateTime не установлен .setLocale()
  • и при создании не передан параметр locale
  • используется Settings.defaultLocale

Если же Settings.defaultLocale не установлен, Luxon делегирует выбор локали среде выполнения (обычно en-US или системная локаль).

Базовое поведение локали при форматировании

Локаль влияет на все методы форматирования:

  • toLocaleString()
  • toFormat()
  • toLocaleParts()
  • toISODate() (косвенно, через некоторые представления)

Пример влияния:

import { DateTime, Settings } from "luxon";

Settings.defaultLocale = "ru";

const dt = DateTime.now();

console.log(dt.toLocaleString(DateTime.DATE_FULL));

При установленной локали ru результат будет использовать русские названия месяцев и порядок даты, например:

23 мая 2026 г.

Если локаль изменить:

Settings.defaultLocale = "en";

console.log(dt.toLocaleString(DateTime.DATE_FULL));

Результат изменится на:

May 23, 2026

Приоритеты локали и переопределение

Luxon использует строгую иерархию:

1. Локаль экземпляра DateTime

const dt = DateTime.now().setLocale("fr");

Этот вариант всегда перекрывает глобальную настройку.

2. Глобальная локаль

Settings.defaultLocale = "de";

Применяется ко всем новым экземплярам без локального override.

3. Локаль среды выполнения

Используется, если не задано ничего выше.

Изменение Settings.defaultLocale в рантайме

Settings.defaultLocale можно изменять в любой момент, и это сразу влияет на все последующие операции форматирования.

import { DateTime, Settings } from "luxon";

const dt1 = DateTime.now();
console.log(dt1.toLocaleString(DateTime.DATE_MED));

Settings.defaultLocale = "ja";

const dt2 = DateTime.now();
console.log(dt2.toLocaleString(DateTime.DATE_MED));

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

Поведение в серверной среде и браузере

В Node.js локаль среды часто зависит от системных настроек операционной системы. Это может приводить к различиям между окружениями.

В браузере локаль обычно определяется настройками пользователя (navigator.language), но Luxon не всегда автоматически использует её, если задан Settings.defaultLocale.

Поэтому явная установка:

Settings.defaultLocale = "en-GB";

обеспечивает предсказуемое поведение независимо от окружения.

Влияние на парсинг и форматирование

Важно различать:

  • Парсинг: создание DateTime из строки
  • Форматирование: вывод даты в строку

Settings.defaultLocale влияет в первую очередь на форматирование. Парсинг ISO-строк (например, fromISO) не зависит от локали.

const dt = DateTime.fromISO("2026-05-23T10:00:00");

Settings.defaultLocale = "ru";

console.log(dt.toLocaleString(DateTime.DATETIME_FULL));

Локаль изменит только представление результата.

Взаимодействие с setLocale()

Метод setLocale() задаёт локаль на уровне конкретного объекта:

import { DateTime, Settings } from "luxon";

Settings.defaultLocale = "ru";

const dt = DateTime.now().setLocale("it");

console.log(dt.toLocaleString(DateTime.DATE_FULL));

Даже при глобальной русской локали формат будет итальянским.

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

Поведение с цепочками DateTime

Luxon использует иммутабельную модель: каждый метод возвращает новый объект.

const dt1 = DateTime.now();
const dt2 = dt1.setLocale("es");
const dt3 = dt2.plus({ days: 1 });

Локаль сохраняется в цепочке, пока не будет явно переопределена.

Если же глобальная локаль изменится после создания dt1, это не изменит его текущую локаль, но повлияет на последующие преобразования без явного override.

Типичные источники неоднозначного поведения

Неожиданная смена языка интерфейса

Если приложение динамически меняет Settings.defaultLocale, это влияет на все компоненты, которые не задают локаль явно.

Несогласованность между модулями

Разные части приложения могут устанавливать defaultLocale, перезаписывая друг друга:

Settings.defaultLocale = "ru";
// где-то в другом модуле
Settings.defaultLocale = "en";

В результате итоговая локаль зависит от порядка импорта.

Отсутствие явной локали

Если не задано ни глобальной, ни локальной настройки, поведение зависит от окружения, что приводит к различиям между dev и prod.

Связь с Intl API

Luxon делегирует форматирование объектам Intl.DateTimeFormat. Settings.defaultLocale фактически становится параметром:

new Intl.DateTimeFormat(locale, options)

где locale берётся из:

  • DateTime.locale
  • Settings.defaultLocale
  • системной локали

Это объясняет, почему Luxon не реализует собственные языковые таблицы — он использует встроенные механизмы JavaScript.

Роль в масштабируемых приложениях

В крупных приложениях глобальная локаль часто используется как стартовое значение:

  • задаётся при инициализации приложения
  • затем переопределяется на уровне пользователя
  • или полностью игнорируется в пользу явных setLocale
Settings.defaultLocale = getUserLocaleFromProfile();

При таком подходе локаль становится частью конфигурационного слоя приложения, а не логики форматирования.

Поведение при смене локали и кеширование

Luxon может кэшировать некоторые внутренние форматтеры Intl.DateTimeFormat. Однако изменение Settings.defaultLocale приводит к созданию новых форматтеров при следующем использовании, поскольку локаль является частью ключа конфигурации форматирования.

Практическое влияние на форматирование стандартных шаблонов

Luxon предоставляет набор предопределённых форматов:

  • DATE_SHORT
  • DATE_MED
  • DATE_FULL
  • DATETIME_FULL

Все они зависят от локали:

Settings.defaultLocale = "fr";

DateTime.now().toLocaleString(DateTime.DATE_FULL);

Формат структуры остаётся тем же, но языковое представление полностью меняется.

Особенности сброса значения

Settings.defaultLocale можно вернуть к неопределённому состоянию:

Settings.defaultLocale = undefined;

В этом случае Luxon снова начинает полагаться на локаль среды выполнения.

Совместимость с SSR и изолированными окружениями

В серверном рендеринге важно учитывать, что глобальные настройки могут разделяться между запросами, если используется общий процесс.

Из-за этого изменение Settings.defaultLocale в одном запросе потенциально влияет на другой, если не используется изоляция контекста выполнения.

Роль в архитектуре локализации

Settings.defaultLocale чаще всего используется как:

  • начальное значение локали
  • fallback при отсутствии пользовательских настроек
  • механизм централизованной настройки форматирования

Однако в архитектурах с высокой нагрузкой предпочтение обычно отдаётся явному setLocale, чтобы избежать глобального состояния.

Оглавление