Движение вперед: усовершенствование расчетов исторических даты и времени в Интернете
Движение вперед: усовершенствование расчетов исторических даты и времени в Интернете
Веб-разработчики стремятся создавать приложения для всего мира, чтобы охватить всех пользователей. Internet Explorer 10 позволяет веб-разработчикам использовать историческое летнее время, уже доступное в операционной системе. Благодаря этому повышается точность при взаимодействии приложений и сайтов с историческими датами и временем в разных часовых поясах.
Ранее в этом году мы изучили API-интерфейсы интернационализации ECMAScript, находящиеся на стадии развития. Они позволят реализовать такие функции, как представление валют и сравнение строк для разных языковых стандартов из платформы веб-стандартов — сценарии, для реализации которых прежде требовалась встроенная поддержка взаимодействия или подключаемые модули. По той же теме, посвященной созданию веб-платформы для всего мира, мы опубликовали демонстрацию, в которой исследуется взаимодействие браузеров с данными об исторической дате и часовом поясе.
Проблемы, связанные с расчетами исторических даты и времени
При работе с историческими датами, например при интерпретации исторических данных о курсе акций, днях рождения или исторических событиях, веб-разработчикам часто приходится выполнять проверку на сервере. Им приходится использовать сервер, поскольку в настоящее время обработчики JavaScript вычисляют поправки на летнее время для дат менее точно, чем платформы, обычно работающие на сервере, такие как .NET, PHP / Perl и Java. Помимо неточности, исторические даты JavaScript зачастую несовместимы между платформами браузеров. В результате разработчики не могут уверенно использовать зависимость от дат с учетом перехода на летнее время, сгенерированных в JavaScript.
Internet Explorer 10 — это первый браузер с более точными датами с учетом перехода на летнее время, в которых учтены изменения, внесенные в раздел 15.9.1.8 черновой спецификации ECMAScript 6. Мы расширили возможности веб-платформы на основе сценариев, в которых веб-разработчики должны взаимодействовать с сервером для выполнения необходимых задач. Изучив, как обработчики JavaScript интерпретируют исторические даты и учитывают переход на летнее время, мы заметили недостаток в спецификации стандартов ECMAScript, препятствующий более точному учету перехода на летнее время в существующих реализациях JavaScript. Мы работали с комитетом по стандартам ECMAScript и предложили изменение спецификации, чтобы сделать следующую версию спецификации ECMAScript более четкой.
Тестовая демонстрация
Чтобы наглядно убедиться в существовании этой проблемы и посмотреть, как ваш браузер работает с историческими датами, ознакомьтесь с тестовой демонстрацией исторических дат, щелкнув любой значок события из истории освоения космоса в нижней части демонстрации. При этом браузер считывает историческую дату события и отображает дату и время, применяя правило перехода на летнее время, заданное по умолчанию в браузере для момента, когда произошло событие. Затем в демонстрации проверяется правильность исторической даты и поправки на летнее время.
В вышеприведенном случае, когда просматривается историческая дата запуска космического корабля IMAGE, Internet Explorer 10, работающий на компьютере Windows 8 в часовом поясе Тихоокеанского времени США (зима), теперь может точно определить правильную дату и летнее время этого исторического события.
Примечание. Летнее время применяется не ко всем часовым поясам. Есть часовые пояса, в которых правила перехода на летнее время никогда не менялись. Если ваша система находится в таком часовом поясе, мы рекомендуем вам изменить часовой пояс системы на тот, где есть правила перехода на летнее время, менявшиеся в течение некоторого периода времени (как в случае Тихоокеанского времени США (зима)), и повторно запустить демонстрацию. Internet Explorer 10 сразу учитывает изменение часового пояса системы. Если же вы используете любой другой браузер, вам, возможно, потребуется его перезапустить, чтобы изменение часового пояса вступило в действие.
Улучшенная обработка исторических дат и времени в Internet Explorer 10
Давайте подробнее рассмотрим, как текущая спецификация ECMAScript влияет на точность скорректированных дат с учетом перехода на летнее время в JavaScript.
В разделе 15.9.1.8 спецификации ECMAScript 5.1 указано, что такие реализации JavaScript, как обработчик Chakra в Internet Explorer, обычно должны следовать следующим правилам при работе с историческими датами:
Реализация ECMAScript не должна пытаться определить, относится ли точное время к летнему времени, а просто определяет, действовало ли бы летнее время, если бы в то время использовался текущий алгоритм перехода на летнее время. При этом не принимаются в расчет такие сложности, как учет тех лет, когда в местности круглый год использовалось летнее время.
Если среда размещения предоставляет функции определения летнего времени, реализация ECMAScript может сопоставить интересующий год эквивалентному году (високосному или не високосному и начинающемуся с того же дня недели), для которого среда размещения предоставляет данные о летнем времени. Единственное ограничение заключается в том, что все эквивалентные годы должны давать одинаковый результат .
Проще говоря, это означает, что для работы с исторической датой реализация JavaScript должна либо применить к ней текущий алгоритм перехода на летнее время, либо определить день недели для 1-го января года, вычислить, был ли год високосным, найти текущие правила перехода на летнее время для года с аналогичными параметрами (день недели первого дня года и является ли год високосным), а затем применить это летнее время к исторической дате. Приведем пример второго подхода. 1972 год был високосным и начинался в субботу. Следующий високосный год, начинавшийся в субботу, был 2000. В соответствии с языковой спецификацией для работы с датами 1972 года реализации JavaScript могли либо использовать текущие правила перехода на летнее время, либо использовать правила для 2000 года.
При использовании обоих этих подходов к применению правил перехода на летнее время к историческим датам возникает две ключевые проблемы. Во-первых, правила перехода на летнее время для конкретного часового пояса меняются с течением времени. Это может привести к применению неправильных правил к исторической дате. Во-вторых, для часовых поясов, в которых правила перехода на летнее время менялись в течение некоторого периода времени, веб-приложения больше не могут поддерживать соответствие с историческими датами, вычисленными платформой операционной системы. Из-за этого разработчикам зачастую приходится "обходить" такие проблемы взаимодействия между веб-приложениями и платформой, на которой они выполняются.
Текст спецификации ECMAScript 5.1 в разделе 15.9.1.8, как мы видели раньше, допускает в реализациях неправильные поправки на летнее время, но ограничивает то, насколько правильными они должны стараться быть. Это довольно нелогично, и на практике не приводит к согласованности между браузерами. Вместо ограничения поведения смещения часового пояса, как в разделе 15.9.1.8, спецификация должна оставить реализацию DaylightSavingsTA зависимой.
Проведенное нами тестирование показало, что ни одна из существующих реализаций браузера (новейших версий) не придерживается полностью поведения, описанного в стандартах для платформ, и не учитывает точно переход на летнее время при работе с датами. Вот несколько примеров, иллюстрирующих это отличие для Тихоокеанского часового пояса США:
| Дата | Windows | Debian | Mac | |||||||
| Internet Explorer 9 | Chrome | Firefox | Opera | Safari | Node | Node | Chrome | Firefox | Safari | |
| 4/1/2000 | 420 | 420 | 420 | 420 | 420 | 420 | 480 | 480 | 480 | 420 |
Обратите внимание, что для этой даты Chrome, FireFox и Node показывают разные значения в разных операционных системах. Фактически, почти все ошибаются, поправка на летнее время была 480.
| Дата | Windows | Debian | Mac | |||||||
| Internet Explorer 9 | Chrome | Firefox | Opera | Safari | Node | Node | Chrome | Firefox | Safari | |
| 3/10/2011 | 480 | 480 | 480 | 480 | 480 | 480 | 480 | 480 | 480 | 480 |
| 3/10/2109 | 480 | 480 | 480 | 480 | 420 | 480 | 480 | 480 | 420 | 420 |
Обратите внимание, что для этой даты некоторые среды снова нарушают правила ES5.1 (оба эти года начались во вторник и не были високосными), но здесь есть несогласованности даже в одной операционной системе (и в Windows, и в Mac).
Заглядывая вперед
Начиная с Internet Explorer 10, обработчик Chakra теперь использует для преобразований между местным временем и временем в формате UTC данные о переходе на летнее время, доступные в платформе Windows, на которой работает браузер.
После того, как мы сообщили о проблеме в спецификации и поработали с комитетом по стандартам ECMAScript над внесением ясности в следующую версию спецификации ECMAScript, чтобы сделать веб-платформу совместимой и более точной, новейший черновик спецификации ECMAScript 6 теперь содержит подробные инструкции по применению улучшенной поддержки правил перехода на летнее время к датам для предоставления более точной информации. Internet Explorer 10 — первый браузер, соответствующий обновленной спецификации. И мы надеемся, что разработчики других браузеров также улучшат поддержку исторических дат и времени для устранения этих проблем в следующих выпусках, позволив веб-разработчикам создавать эффективные приложения для всего мира.
Поскольку важность веб-платформы продолжает расти, сложная логика приложения теперь зачастую полностью программируется на JavaScript. Это относится и к приложениям для ведения календаря, таблицам, программам для управления проектами и т. п. Чтобы разработчики могли обеспечивать совместимость, это изменение включено только в стандартном режиме Internet Explorer 10. Если вы вычисляете исторические даты в ваших веб-приложениях и используете собственную логику для устранения неточностей браузеров, вы наверняка хотите обеспечить правильную работу этой логики после обновления ваших веб-приложений для работы в Internet Explorer 10.
— Суреш Джаябалан (Suresh Jayabalan), руководитель программы, группа JavaScript