Опция Chrome timeZone для Date.toLocaleString()

Недавно я обнаружил, что есть новое расширение для JavaScript. Это добавляет несколько функций к Date объект в toLocaleString, toLocaleDateString а также toLocaleTimeString функции. Ссылка здесь.

Я особенно заинтересован в timeZone опция, которая поддерживает часовые пояса IANA/Olson, например America/New_York или же Europe/London, В настоящее время это поддерживается только в Google Chrome.

Предыдущий совет заключался в том, что для работы в JavaScript с любым другим часовым поясом, кроме UTC или вашим собственным часовым поясом, нужно было использовать библиотеку. Но теперь, похоже, это начинает включаться непосредственно в браузер. Так что теперь вы можете сделать это:

new Date().toLocaleString("en-US", {timeZone: "America/New_York"})

// output: "7/4/2013 5:15:45 PM"

Или же:

new Date().toLocaleString("en-NZ", {timeZone: "Pacific/Chatham",
                                    timeZoneName: "long"})

// output:  "7/5/2013 9:59:52 AM GMT+12:45"

Или же:

new Date().toLocaleString("en-GB", {timeZone: "Europe/London",
                                    timeZoneName: "short"})

// output:  "4/7/2013 22:18:57 United Kingdom Time"
// (strange time zone name, but ok)

Это очень круто, но у меня есть несколько вопросов:

  • Является ли это частью нового стандарта? Возможно, похоронен где-то в ECMAScript 6? Или это просто что-то нестандартное для Chrome?
  • Почему только Google Chrome? Это поддерживается где-нибудь еще? Есть ли планы поддержать его где-нибудь еще?
  • Я проверил node.js, который использует среду выполнения Chrome JavaScript, но там он не работает. Почему бы и нет?
  • Доступны ли данные часового пояса каким-либо иным способом, кроме функций, которые я перечислил? Если доступно только при форматировании строк, выполнение любых вычислений на основе результатов может быть затруднено.

  • Это ориентировано на вывод, но как бы я использовал его для ввода? Есть ли способ передать часовой пояс в конструкторе Date объект? Я попробовал следующее:

    // parsing it with a date and time
new Date("2013-01-01 12:34:56 America/New_York")

// passing it as a named option
new Date(2013,0,1,12,34,56,{timeZone:"America/New_York"})

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

  • Проблема, описанная в этом посте, вызванная недостатком спецификации ECMAScript 5, все еще влияет на вывод, даже когда правильные данные находятся в TZDB. Как сосуществуют как старые, так и новые реализации? Казалось бы, все будет по-старому или по-новому. Например, с часовым поясом моего компьютера, установленным на восточное время США:

    new Date(2004,10,7,0,0).toLocaleString("en-US",{timeZone:"America/New_York"})

    возвращается "11/6/2004 11:00:00 PM", Он должен вернуться в полночь, так как я начал в полночь, и мой местный часовой пояс совпадает с выходным часовым поясом. Но он помещает предоставленную дату ввода в неправильную точку UTC из-за проблемы ES5.

  • Могу ли я ожидать, что когда IANA выпустит обновления для TZDB, Google отправит обновления Chrome, содержащие эти изменения?

Источник

2 ответа

Решение

Обновить

Здесь довольно обширная статья об API

Является ли это частью нового стандарта? Возможно, похоронен где-то в ECMAScript 6? Или это просто что-то нестандартное для Chrome?

Да, это часть API интернационализации ECMAScript. Он реализован отдельно от ECMAScript, но требование реализации Интернационализации API ECMAScript состоит в том, чтобы сначала иметь правильную реализацию ECMAScript 5.1

Почему только Google Chrome? Это поддерживается где-нибудь еще? Есть ли планы поддержать его где-нибудь еще?

В последние годы Google Chrome был первым, кто внедрил новые функции. Mozilla более консервативна, все еще, например, обсуждает, следует ли download атрибут a элементы. Теперь он доступен и в бета-версии IE11, и в Opera. Это будет доступно в Firefox 25.

Я проверил node.js, который использует среду выполнения Chrome JavaScript, но там он не работает. Почему бы и нет?

node.js просто использует тот же движок, который является отдельным проектом от браузера Google Chrome. Движок просто реализует Ecmascript 5.1. Это расширение node.js пришлось бы реализовывать отдельно прямо сейчас. Он станет доступен в V8 в Q3, так что, возможно, чуть позже вы сможете использовать его в node.js.

Это ориентировано на вывод, но как бы я использовал его для ввода? Есть ли способ передать часовой пояс в конструкторе объекту Date? Я попробовал следующее:

Нет ничего о вводе дат в спецификации. Я лично не понимаю, как это было бы полезно, вы делаете это неправильно, если вы не передаете метки времени UTC, потому что что-то вроде "2013-01-01 12:34:56 America/New_York" неоднозначно при переходах с летнего времени на стандартное время.

Проблема, описанная в этом посте, вызванная недостатком спецификации ECMAScript 5, все еще влияет на вывод, даже когда правильные данные находятся в TZDB.

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

Могу ли я ожидать, что когда IANA выпустит обновления для TZDB, Google отправит обновления Chrome, содержащие эти изменения?

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

Источник

Является ли это частью нового стандарта? Возможно, похоронен где-то в ECMAScript 6? Или это просто что-то нестандартное для Chrome?

Действительно, это часть нового стандарта ECMA-402. Стандарт очень трудно читать, но есть это дружественное введение.

Почему только Google Chrome? Это поддерживается где-нибудь еще? Есть ли планы поддержать его где-нибудь еще?

У MDN есть список поддерживаемых браузеров. Согласно сообщению об ошибке 853301, он будет доступен в Firefox 25.

Я проверил node.js, который использует среду выполнения Chrome JavaScript, но там он не работает. Почему бы и нет?

Возможных причин много; это не соответствует текущей кодовой базе, или это сделало бы файл node.js больше и медленнее (предыдущая запись в трекере ошибок от Mozilla указывает, что данные часового пояса увеличили размер загрузки Firefox на 10 % и вызвали ввод-вывод существенно увеличить при запуске браузера.

Доступны ли данные часового пояса каким-либо иным способом, кроме функций, которые я перечислил? Если только
доступно при форматировании строк, тогда выполнение любых вычислений на основе результатов может быть затруднено.

Кажется, что это не доступно. Более того, в учебнике по API Intl говорится, что только UTC и местный часовой пояс обязательно должны поддерживаться.

Это ориентировано на вывод, но как бы я использовал его для ввода? Есть ли способ передать часовой пояс в конструкторе объекту Date? Я попробовал следующее:

Интерфейс API говорит только о форматировании даты / времени, сопоставления строк и форматирования чисел. Форматирование даты и времени поддерживает не только григорианский календарь, но также многие другие календари, лунный, лунный и тому подобное.

Проблема, описанная в этом посте, возникшая из-за ошибки в спецификации ECMAScript 5, все еще влияет на вывод, даже когда правильные данные находятся в TZDB. Как сосуществуют как старые, так и новые реализации? Казалось бы, все будет по-старому или по-новому. Например, с часовым поясом моего компьютера, установленным на восточное время США:

новая дата (2004,10,7,0,0).toLocaleString("en-US",{timeZone:"America/New_York"})

возвращает "6.11.2004, 11:00:00". Он должен вернуться в полночь, так как я начал в полночь и> мой местный часовой пояс совпадает с выходным часовым поясом. Но он помещает предоставленную дату ввода в> неправильную точку UTC из-за проблемы ES5.

Причина этого заключается в том, что ES5 требует, чтобы входные данные для новой даты были рассчитаны с использованием текущего летнего времени и смещения, то есть это Америка / Нью-Йорк, но с часовым поясом EDT, даже если 6 ноября не в EDT. Очевидно, как это указано, тогда его нельзя изменить. Тем не менее, поскольку Chrome использует TZDB для преобразования чистого значения времени UTC в значение tz Америка / Нью-Йорк, он тогда считает время в EST.

Могу ли я ожидать, что когда IANA выпустит обновления для TZDB, Google отправит обновления Chrome, содержащие эти изменения?

Я бы так поверил

Источник
Другие вопросы по тегам