Intl.DateTimeFormat () с параметрами формата не работает для 'it-CH'

Question

Я получаю локаль с сервера и пытаюсь отформатировать заданную дату на основе этих опций форматирования локали и дополнительных опций.Он работает со всеми локалями, но it-CH

date = new Date(2010,0,1)
new Intl.DateTimeFormat('it-CH', {day:'2-digit', month:'2-digit', year:'numeric'}).format(date)
// output: "01.01.2010"

Правильный вывод должен быть 01/01/2010

Он работает для локали it:

new Intl.DateTimeFormat('it', {day:'2-digit', month:'2-digit', year:'numeric'}).format(date)
// output: "01/01/2010"

Или с языком it-CH, если я не включаю форматирование года в опциях:

new Intl.DateTimeFormat('it-CH', {day:'2-digit', month:'2-digit'}).format(date)
// output: "01/01"

Правильный вывод должен быть 01/01/2010.Я протестировал его на Windows и Mac OS в последних версиях Chrome.Откуда происходит это странное поведение, как я могу это исправить?

Answer 1

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

Ситуация довольно сложная.«Язык» - это языковой тег BCP 47 .Список тегов и подтегей поддерживается IANA и время от времени изменяется.Кроме того, отображение форматов на теги и вложенные теги зависит от реализации.

Суть в том, что существует неопределенность в отношении того, какой формат должен применяться к конкретному языку и варианту, и огромное количество локальных языков и вариантов (например, племенные языки) вообще не поддерживаются.Поэтому не полагайтесь на то, что toLocaleString будет выполнять всю работу и все время получать ее правильно.

Альтернатива оставлению всего этого на усмотрении - ручное форматирование даты в однозначномотформатируйте toLocaleString для языка отдельных компонентов.Таким образом, когда определенный язык не поддерживается, вы можете вернуться к языку браузера по умолчанию (см. PPS ниже) и быть уверенным, что то, что вы помещаете на страницу, понятно и не оставляет его полностью для реализации, например

function getFormattedDate(d, lang){
  return d.getDate().toLocaleString(lang) + ' '
    + d.toLocaleString(lang, {month:'long'}) + ', '
    + d.toLocaleString(lang, {year:'numeric'});
}

var d = new Date();
['it-CH', 'en-GB', 'ar-EG', 'zu-ZA', 'hz', undefined].forEach(
  lang => console.log((lang||'Default') +
          ': ' + getFormattedDate(d, lang))
);

Не зацикливайтесь на поддержке всех возможных форматов и вариантов языка.Гораздо важнее обеспечить, чтобы даты были однозначными, а не были ли компоненты разделены запятыми, тире, косой чертой или чем-то, что обычно используется в локальном варианте.Когда я смотрю на официальную переписку в моей локали, даты представлены в 3 или 4 разных форматах, часто два разных формата используются на одной странице (например, в заголовках, текстовых и табличных данных).

PS : Вы также должны проверить поддержку для toLocaleString перед ее использованием.

PPS : Было бы очень хорошо, если быбыл способ проверить, поддерживается ли языковой тег перед его использованием, но, насколько я могу судить, это невозможно.Например, в приведенном выше примере «hz» - это Herero , язык, на котором говорит определенная этническая группа в южной части Африки, и который, вероятно, не поддерживается ни одним браузером, поэтому он должен использовать язык браузера по умолчанию.