Параметр 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, который использует время выполнения JavaScript 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, содержащие изменения?

Ответы

Ответ 1

Обновление

Существует довольно обширная запись об API здесь

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

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

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

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

Я проверил node.js, который использует время выполнения JavaScript 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" неоднозначно во время переходов с DST на стандартное время.

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

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

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

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

Ответ 2

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

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

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

В MDN есть список поддерживающих браузеров. В соответствии с Ошибка 853301 он будет доступен в Firefox 25.

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

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

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

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

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

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

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

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

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

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

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

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