Знаете, есть такая функция в 1С - Формат. Она позволяет представить, например, даты в строковом виде. Вот, например, новый год, час ночи это 1 января 2025, 01:01:00. Сам по себе момент времени нельзя сообщить другому человеку, его надо каким-то образом представить в виде букв и/или цифр, например, как это сделал я только что. А можно еще написать 01.01.2025 1:01:00 или 2025-01-01T01:01:01. Способов представления дат много, и все они превращаются в человекочитаемый вид с помощью процесса, называемого "форматирование".
Так получилось, что человеков на Земле много, и живут они на ней достаточно давно. А потому и общепринятых способов написания дат они успели создать больше одного. И даже больше десяти.
А еще есть нестандартные алфавиты цифр в арабских странах и Азии, а также лунные календари...
Самое неприятное, что все эти люди пользуются компьютерами, а айтишники должны обеспечить представление дат на любой вкус клиента, независимо от гражданства, вероисповедания и приверженности лунному календарю. Наверняка вы знаете, что в США принят формат Месяц/День/Год и 12-часовой цикл с суффиксом AM/PM, а тот же английский формат, но в старушке Британии будет представлять дату более человеческим образом, хотя и со слешами: День/Месяц/Год и, как правило, 24-часовое время вместо AM/PM.
Как написать интернационализированное приложение и не сойти с ума? Можно выучить все языки в мире или нанять в штат консультантов представителей разных культур, но кажется, правильнее будет создать международную кооперацию, которая покумекает-покумекает и выдаст базу данных со всеми возможными вариантами форматирования дат: месяцы прописью, в разных падежах разных языков, разделители, символы цифр иероглифами и так далее и так далее...
И такая база данных существует. Называется она CLDR (Common Locale Data Repository) и все вменяемые фреймворки ее используют. Именно поэтому в вашей 1С в функции "Формат" вы можете указать китайское форматирование дат, и оно будет работать. 1С использует библиотеку ICU, которая, в свою очередь, использует CLDR и поэтому платформа знает, как выглядит первое января на Суахили.
Не отстают от 1С и браузеры. Встроенный в них Javascript тоже использует CLDR. И наша любимая (нет) Java, начиная с 8-й версии тоже задолбалась поддерживать собственные данные по локализации и переехала на CLDR.
Что же получается - теперь все мейнстримные языки сидят на единой базе локализационных данных, а значит форматы дат в них будут одинаковыми и совместимыми? Да, так и есть. Клево правда?
Было бы, если бы эта хренова база знаний была стабильной. Например, в 11 яве отвалились локализованные на немецкий суффиксы AM/PM, потому что 17 Java обновила CLDR в которой немцев лишили немецких суффиксов (фрустрация тут)
Вернемся к нашей дате 1 января, час ночи. Представьте, что вы пишете некий фреймворк, который работает и на бэкенде и в браузере (кто сказал "Элемент"?) и вам нужно сделать функцию форматирования дат с учетом локализации. Если вы в своем уме, то вариант "написать вручную все в мире варианты форматов дат самостоятельно" вы отметаете сходу и говорите: "У нас же есть CLDR! А она есть и в яве и в браузерах и даже в 1Сv8! Ништяк!"
Кстати, как будет в русской локали 2025-01-01 01:01:01 если форматировать в 1Сv8? А в 11 яве? Не бегите проверять, я уже это сделал. Одинаково! Прям вообще одинаково, зашибись же! И будет равняться "01.01.2025 1:01:01" (час одноразрядный, остальные единицы - двуразрядные)
А теперь, предположим, мы решили обновить "платформу" и запустили наше приложение под явой 17. Совпадает? Как не совпадает, почему? А по кочану.
Java17 использует другую версию CLDR, там час в русской локали - двуразрядный, но зато теперь она совпадает с форматированием в браузере Chrome. Да, ваш предыдущий код сломался, верстка форм разъехалась, алгоритмы, заточенные на длину строк поплыли, но вы ж программист, почините!