segunda-feira, 10 de março de 2008

MS quer transformar bug em standard

Quando surgiu o Excel, vinha com um bug na função DATE(), e considerava 1900 como um ano bissexto. As regras dos anos bissextos são algo curiosas; de quatro em quatro anos Fevereiro tem mais um dia. Exceptuam-se os anos múltiplos de 100. E a esta excepção exceptuam-se os anos múltiplos de 400. Segundo a Microsoft o dia 29 de Fevereiro de 1900 existiu. E na proposta de standard do novo formato do MS Office 2007 à ECMA, também deverá "existir", por questões de "compatibilidade" ...


As piadas são velhas mas ainda valem:

P - Quantos engenheiros da Microsoft são necessários para se trocar uma lâmpada?
R - Nenhum. Simplesmente se define Escuro™ como o novo padrão.

Uma "feature" é um "bug" que não pode ser resolvido

Infelizmente, a proposta aprovada pela ECMA para o Open XML faz com que essas piadas pareçam muito verdadeiras.

Além de criar um formato praticamente impossível de ser implementado na íntegra por qualquer concorrente, a Microsoft resolveu incluir no "padrão", bugs que vêm sendo carregados desde a criação do seu pacote de automação de escritórios.

O bug "padronizado" é relativo ao tratamento de dias da semana pelo Excel. Um bug que já é velho conhecido da própria Microsoft como pode ser visto no próprio sítio de suporte da empresa.

O calendário gregoriano resolveu um problema do padrão anterior, o calendário juliano, ao criar uma regra para anos bissextos que fossem divisíveis por 100: somente são bissextos os anos que além de divisíveis por 100 também o sejam por 400. Esta simples correção permitiu que pudéssemos finalmente mapear as estações do ano ao calendário. Afinal, ninguém quer passas as férias de verão fora de época.

O bug a que me refiro acontece porque a Microsoft, no desenvolvimento do Excel, resolveu usar uma forma diferente para lidar com datas, adotando um valor serial para as datas tendo como início o dia 1 de janeiro de 1900. O problema com esta forma de cálculo de datas é que, para funcionar, o ano de 1900 teria que ser bissexto. E 1900 é considerado pelo Excel, e pelas demais fórmulas de data, como sendo um ano bissexto, apesar de não atender à regra de divisão por 100 e 400.

Mas o que isso tem a ver com o Open XML? A seção section 3.17.4.1, página 2522 do volume 4 da especificação publicada pela ECMA diz:
For legacy reasons, an implementation using the 1900 date base system shall treat 1900 as though it was a leap year. [Note: That is, serial value 59 corresponds to February 28, and serial value 61 corresponds to March 1, the next day, allowing the (nonexistent) date February 29 to have the serial value 60. end note] A consequence of this is that for dates between January 1 and February 28, WEEKDAY shall return a value for the day immediately prior to the correct day, so that the (nonexistent) date February 29 has a day-of-the-week that immediately follows that of February 28, and immediately precedes that of March 1.


Ou seja, apesar de haver um padrão de datas reconhecido e utilizado internacionalmente, a Microsoft optou por padronizar o Escuro™ ao invés de trocar a lâmpada.

A intenção de padronizar o Escuro™ não para aí. A Apple também adotou um formato de data serial, só que, para fugir do problema do ano de 1900, iniciou a contagem em 1 de janeiro de 1904. O resultado é que o Excel no Mac, teve que ser adaptado para contornar este pequeno problema. O resultado também está na especificação do Open XML, na seção 3.2.28:
date1904 (Date 1904)
Specifies a boolean value that indicates whether the date systems used in the workbook starts in 1904.
A value of on, 1, or true indicates the date system starts in 1904.
A value of off, 0, or false indicates the workbook uses the 1900 date system, where 1/1/1900 is the first day in the system.
The default value for this attribute is false.


Uma das razões para usarmos padrões abertos é justamente separar o padrão da implementação. Estes são apenas dois exemplos de padronização do Escuro™ pela Microsoft no Open XML.

A ISO tomou uma posição e terá que se manifestar novamente quando da chegada do Open XML às suas portas.

A nós cabe decidir se queremos pensar no futuro ou nos mantermos firmemente ancorados aos erros do passado.

Referências:
NoOOXML
Blog Trocando Lâmpadas