Um salto a frente: avanços em cálculos de históricos de data e horário na Web

Um salto a frente: avanços em cálculos de históricos de data e horário na Web

Os desenvolvedores da Web querem criar aplicativos que estejam prontos para o mundo para alcançar uma audiência global. O Internet Explorer 10 traz o histórico de horário de verão, já disponível no sistema operacional subjacente, para o desenvolvedor da Web. Isso permite que aplicativos e sites interajam com datas e horários do histórico por meio de diversos fusos horários com maior precisão.

No início do ano, exploramos os APIs de internacionalização ECMAScript que estão surgindo e que permitirão funcionalidades como representações de moedas e comparações de strings que detectam localidade, dentro da plataforma padrão da Web. Tais cenários dependiam de interoperabilidade nativa ou do uso de um plug-in. Relacionado ao mesmo assunto de tornar a plataforma da Web pronta para o mundo, publicamos uma demonstração que explora como os navegadores interagem com as informações do histórico da data e fuso horário.

Desafios relacionados aos cálculos de histórico de data e fuso horário

Ao interagir com datas históricas, como interpretar o histórico de preços do mercado de ações ou aniversários ou eventos históricos, os desenvolvedores da Web geralmente têm de realizar uma validação no servidor. Os desenvolvedores dependem do servidor porque os ajustes no horário de verão feitos nas datas pelos mecanismos JavaScript hoje não são tão precisos quanto as plataformas tipicamente executadas no servidor como .NET, PHP / Perl e Java. Além do fato das datas históricas do JavaScript não serem precisas, por diversas vezes elas não são interoperáveis entre as plataformas dos navegadores. Sendo assim, os desenvolvedores não conseguem considerar as dependências nas datas DST ajustadas que são geradas no JavaScript.

O IE10 é o primeiro navegador com mais datas de ajuste DST precisas alinhadas com as mudanças feitas na seção 15.9.1.8 da especificação de rascunho do ECMAScript 6. Aumentamos as funcionalidades da plataforma da Web com base nos cenários onde os desenvolvedores da Web têm de interagir com o servidor para realizar suas necessidades. Vimos como os mecanismos do JavaScript interpretam datas históricas e as ajustam para DST. Percebemos uma falha na especificação dos padrões ECMAScript que impossibilita que implementações existentes do JavaScript sejam mais precisas no ajuste para o horário de verão. Trabalhamos com a comissão de padrões do ECMAScript e propomos uma mudança na especificação para trazer mais clareza para a próxima versão da especificação do ECMAScript.

Explorando a demonstração de ''test drive''

Para ilustrar esse problema e ver como o seu navegador preferido lida com as datas históricas, você pode utilizar a demonstração de ''test drive'' das datas históricas clicando em qualquer ícone de um evento no histórico aeroespacial na parte inferior da demonstração. Quando fizer isso, seus navegador lerá a data histórica de quando o evento ocorreu e mostrará a data e o horário aplicando a regra do horário de verão que o navegador omitiu quando o evento ocorreu. A demonstração então verifica se a data histórica e o horário de verão estão corretos ou não.

No caso acima, ao exibir a data histórica do momento em que a nave espacial IMAGE foi lançada, o IE10 executado em uma máquina com Windows 8 no fuso horário padrão do Pacífico agora pode determinar com precisão a data correta e o horário de verão para o evento histórico.

Observação: O horário de verão não existe em algumas regiões. E, em certas regiões, as regras do fuso horário nunca mudaram. Se o seu sistema se encontra em alguma dessas regiões, recomendamos que você altere o fuso horário do seu sistema para um em que as regras de horário de verão existam e tenham mudado depois de um certo tempo (como o horário padrão do Pacífico) e execute novamente a demonstração. Enquanto o IE10 detecta imediatamente uma alteração de fuso horário do sistema, em outros navegadores, você talvez precise reiniciar o navegador para que o fuso horário seja atualizado.

Manipulação aperfeiçoada das datas históricas e horários no IE10

Vamos analisar como as especificações do ECMAScript atuais impactam a precisão ao ajustarmos as datas para DST no JavaScript:

A seção 15.9.1.8 do ECMAScript 5.1 especifica que as implementações de JavaScript, como o mecanismo Chakra do Internet Explorer, devem ser seguidas normalmente ao lidar com datas históricas:

A implementação do ECMAScript não deve tentar determinar se o horário exato estava sujeito ao horário de verão, e sim se o horário de verão já estava em vigor caso o algorítimo do horário de verão atual tenha sido usado naquela hora. Isso evita complicações como considerar os anos em que o horário de verão local cumpriu o seu ciclo.

Se o ambiente de hospedagem fornece funcionalidade para determinar o horário de verão, a implementação do ECMAScript é gratuita para mapear o ano em questão para um ano equivalente (como é o caso dos anos bissextos e dias iguais que iniciam a semana no ano) para o qual o ambiente de hospedagem fornece informações sobre o horário de verão. A única restrição é que todos os anos equivalentes devem produzir o mesmo resultado .

Em poucas palavras, isso significa que ao lidar com uma data histórica, uma implementação JavaScript ou deve aplicar o algorítimo de horário de verão atual em uma data histórica, ou determinar o dia 1º de janeiro de um ano, calcular se é um ano bissexto, localizar as regras de horário de verão para um ano com os mesmo atributos (primeiro dia do ano e ano bissexto) e aplicar aquele horário de verão específico à data histórica. Exemplificando o último, o ano de 1972 foi um ano bissexto que começou em um sábado. E o ano bissexto seguinte que começou em um sábado foi o ano de 2000. De acordo com a especificação de linguagem, as implementações de JavaScript poderiam usar as regras atuais ou usar as regras do horário de verão do ano de 2000 enquanto manipulam quaisquer datas para o ano de 1972.

Existem dois problemas-chave quando qualquer uma das duas regras acima é usada para aplicar as regras de horário de verão em datas históricas. Primeiro, as regras de horário de verão para um fuso horário específico não são constantes e mudam conforme o tempo. Isso pode fazer com que regras inadequadas sejam aplicadas à data histórica. Segundo, para fusos horários onde as regras de horário de verão mudaram ao longo dos anos, os aplicativos da Web não podem mais manter a paridade para aquelas datas históricas como foi calculado pela plataforma do sistema operacional em que estão sendo executados, o que geralmente força os desenvolvedores a buscarem soluções para os problemas de interoperabilidade entre os aplicativos da Web e a plataforma em que estes estão sendo executados.

O texto de especificação do ECMAScript 5.1 no 15.9.1.8, como vimos acima, permite que as implementações estejam erradas em relação ao horário de verão, mas forçam para que sejam corrigidas. Isso é um pouco intuitivo e, na prática, não gerou consenso entre os navegadores. Em vez de restringir o comportamento de compensação do fuso horário como visto na seção 15.9.1.8, a especificação deve deixar a implementação DaylightSavingsTA dependente.

Nossos testes mostraram que nenhuma das implementações de navegadores existentes (versões mais recentes) adere completamente a um dos comportamentos especificados nas plataformas padrão ou é precisa nos ajustes DST quando lidam com datas. Aqui estão alguns exemplos que mostram a diferença no fuso horário do Pacífico Americano:

Data	Windows					Debian	Mac
	IE9	Chrome	Firefox	Opera	Safari	Node	Node	Chrome	Firefox	Safari
4/1/2000	420	420	420	420	420	420	480	480	480	420

Observe que nesta data Chrome, FireFox e Node estão inconsistentes em relação aos sistemas operacionais. Mas, na verdade, quase todos estão errados, o ajuste real de DST era 480.

Data	Windows					Debian	Mac
	IE9	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

Observe que nessa data poucos ambientes eram contra a violação das regras ES5.1 (esses dois anos começaram em uma terça-feira e não são anos bissextos), mas há divergências até mesmo em um único sistema operacional (ambos em Windows e Mac).

De olho no futuro

Começando com o Internet Explorer 10, o mecanismo Chakra agora usa as informações de horário de verão disponíveis da plataforma do Windows que o navegador executa para conversões entre horário local e UTC. 

Após reportarmos o problema com as especificações e trabalharmos com a comissão de padrões do ECMAScript para trazer mais clareza para a próxima versão da especificação do ECMAScript e, dessa maneira, permitir que a plataforma da Web seja interoperável e mais precisa, o último rascunho da especificação do ECMAScript 6 detalhará como o suporte melhorado e preciso para regras de horário de verão deve ser aplicado à datas para produzir informações mais precisas. O IE10 é o primeiro navegador que se adapta à especificação atualizada e esperamos que outros navegadores também melhorem seus suportes para resolver os problemas em seus próximos lançamentos, permitindo que os desenvolvedores da Web criem aplicativos mais avançados e prontos para o mundo.

Como a plataforma da Web continua a crescer em importância, a lógica avançada dos aplicativos agora é frequentemente escrita em JavaScript, incluindo as usadas pelos aplicativos de calendário, planilhas, softwares de gerenciamento de projeto, etc. Para permitir que desenvolvedores mantenham a compatibilidade, essa mudança só está habilitada no modo padrão do IE. Caso você calcule datas históricas nos seus aplicativos da Web e utilize lógica personalizada para lidar com as imprecisões dos navegadores, verifique se a sua lógica personalizada ainda funciona corretamente após fazer a atualização de seus aplicativos da Web para que funcionem no IE10.

-- Suresh Jayabalan, gerente de programa, equipe JavaScript