1 Trabalhando com zonas horárias
Dados baseados em tempo são uma exigência bastante comum em muitas aplicações. [XML Schema] fornece vários de tipos de dados para datas e horas, tais como date, time, e dateTime. Estes tipos de dados seguem os formatos amigáveis definidos pela [ISO 8601] e podem ser usados para servir a aplicações que diferem na maneira como tratam data ou hora .
Os tipos de dados date, time, e dateTime podem tanto incluir como omitir as diferenças horárias entre as zonas horárias. A presença (ou a ausência) destas diferenças implicam em diferentes maneiras de manipular dados por certos tipos de aplicação. E ainda mais, declarações de datas e horas usando distintas zonas horárias ou distintas diferenças de horário afetam a maneira como os dados são manipulados por uma aplicação particular, assim como a maneira como devem ser manipulados os dados sem qualquer indicação de zona horária ou diferença horária.
Nota: Usuários, desenvolvedores de especificações e de implementações de linguagens que tenham dados relacionados a tempo e hora a manipular, deverão levar em consideração as recomendações a seguir, ainda que dados sensíveis as zonas horárias sejam raramente usados. Mais cedo ou mais tarde algum destes dados será afetado por algum aspecto aqui descrito. Alguns exemplos podem ser citados em XQuery, XPath, e XSLT.
1.1 Background
Existem três principais aplicações de data, hora ou grupo data/hora nas aplicações.
-
Incremental ou Computer Time. A maioria das linguagens de programação e dos ambientes de desenvolvimento geram tipos de dados para manipulação de tempo baseados em um valor numérico: medida em uma unidade de grandeza específica com base em um ponto de referência (conhecido como epoch - era, época). Por exemplo, a declaração em Java java.util.Date é um valor (inteiro) que expressa o número de milisegundos desde às 00:00h (meia-noite) de 01 de janeiro de 1970 em UTC (Universal Coordinated Time, também conhecido como GMT). Outros sistemas usam outras unidades e outros pontos de referência. Valores de data e hora baseados neste tipo de construção (que chamaremos de computer time) são independentes de zona horária, de vez que para um determinado instante o horário UTC será sempre o mesmo em qualquer lugar da Terra: o valor do horário pode ser transformado de modo a exibir o horário em qualquer zona horária e este horário não esta amarrado a nenhum lugar específico. Este tipo de horário é comumente usado em aplicações como as "time stamps", mostrando quando um evento ocorreu. A seguir algumas aplicações que empregam este tipo:
-
de rotulação de horários de entradas em arquivos de log
-
de gravação de hora de início e paradas de um processo
-
de medida de duração de tempo de um evento
-
de comparação de dois valores de tempo
-
Time Zone Independent Field-Based Time. A representação humana para o Computer Time é mais complicada e representa o tempo através do uso de vários campos contendo valores de tempo, tais como hora, minuto, segundo, mês ou ano. Aplicações para este tipo de representação são independentes de zona horária e para eventos que não estão atrelados a um horário particular na Terra. Por exemplo, variados tipos de "data de aniversário" tais como data do aniversário de uma pessoa ou data de admissão de um funcionário, normalmente serão enquadrados nesta categoria dado ao fato de que para estes casos o tempo não é relevante nem o horário de início e fim do dia em determinado local geográfico é importante. A seguir algumas outras aplicações que empregam este tipo:
-
ùltimo dia do trimestre
-
programação para feriados
-
último dia de uma oferta em promoção
-
data de início e fim de períodos legais
-
Time Zone Dependent Field-Based Time. Em outras circunstâncias datas e horários baseados em campos estão atrelados a uma determinada localidade ou a uma determinada zona horária. Por exemplo, se você combina com um amigo que encontra-se em Londres que irá telefonar de Paris às 14:00, seu amigo ficará na espera que o telefone toque às 13:00. Com o uso de tempo incremental, um evento acontece no mesmo horário em qualquer lugar do globo terrestre e a transformação para o horário local faz-se pela diferença horária referente a UTC. A seguir algumas outras aplicações que empregam este tipo:
1.2 Identificando zonas horárias e diferenças horárias
A representação léxica em [XML Schema] segue a norma [ISO 8601]. Valores de data e de hora na ISO 8601 são baseados em campos usando as definições acima e podem indicar (ou omitir) a diferença horária para UTC. Uma diferença horária para uma zona não é o mesmo que zona horária, e a diferença pode ser importante. XML Schema suporta apenas diferença de horário, mas, confusamente chama isto de zona horária, veja por exemplo a seção 3.2.8.1, representação léxica em [XML Schema].
Embora a ISO 8601 esteja expressa em calendário Gregoriano, poderá ser usada para representar valores em qualquer sistema de calendário. A representação de data e hora e de valores de tempo para usuários finais usando diferentes calendários e diferentes sistemas de referências é separada da representação léxica.
O que é "diferença de horário de uma zona"? Diferença de horário de uma zona é a diferença em horas e minutos entre uma zona particular e UTC. Na ISO 8601, uma diferença horária para uma zona pode ser indicada por um valor de data ou de hora. A diferença de horário pode ser expressa por Z ou UTC ou pode ser um valor "+" ou"-" em relação a UTC. Por exemplo, o valor 08:00-08:00 representa 8:00 AM numa zona horária 8 houras atrás de UTC, o que equivale a 16:00Z (8:00 mais oito horas). O valor 08:00+08:00 representa um incremento em sentido contrário ou seja meia-noite (08:00 menos oito horas).
O que é "zona horária"? Zona horária é um identificador para um local específico ou uma determinada região cuja finalidade e a de servir como base para cálculos que determinem qual é a diferença horária para UTC. Por exemplo, quando um website nos Estados Unidos fornece um calendário de programações para encontros e prevê um encontro para às 08:00 Pacific Time, estará se referindo a hora as vezes conhecida como "wall time" (assim chamada por ser a hora marcada no relógio (ou calendário) "on the wall" - pendurado na parede). Esta hora não é equivalente a 08:00-08:00 e nem a 08:00-07:00, porque o Pacific Time não tem, um valor fixo de diferença de horário para UTC; ao contrário, a diferença de horário muda durante o curso do ano. Como já mencionado anteriormente XML Schema suporta somente diferenças horárias, e não faz distinção em termos de terminologia entre diferença horária e zona horária. Assim um " wall time" expresso com um valor time em XML Schema, deve escolher que diferença horária adotar. Isto causará um efeito não esperado de alterar em uma (ou mais) horas o horário programado para um evento sempre que o "wall time" mudar ou houver mudança Daylight/Summer time (horário de verão).
Para complicar, as regras para determinação da data em que ocorrerão as mudanças para horário de verão são complexas e variam de ano para ano e de local para local. O estado de Indiana nos Estados Unidos, por exemplo, não adota o horário de verão que acontecerá em Abril de 2006. Ver: http://www.mccsc.edu/time.html para maiores informações. Os hemisférios do Norte e do Sul adotam o horário de verão em períodos opostos do ano (correspondentes às diferenças sazonais entre os dois hemisférios)
Para poder tratar com estas situações todas, um sistema de calendário deve estar identificado com uma ID para a zona horária. A referência para tratar com o wall time é o banco de dados TZ (tambem conhecido como "Olson time zone database" [tzinfo]), que é usado por diversos sistemas operacionais comerciais UNIX , Linux, Java, CLDR, ICU, e tantos outros sistemas e bibliotecas. EM banco de dados TZ, "Pacific Time" é marcado com a ID America/Los_Angeles. O banco de dados TZ prevê ainda " aliases" para várias IDs; por exemplo, Asia/Ulan Bator é equivalente a Asia/Ulaanbaatar. Daí pode derivar-se ainda um identificador em forma canônica. A Common Locale Data Repository [CLDR] pode ser usada para fornecer uma forma de ID localizada: ver Apêndice J em [UAX 35].
1.3 Incremental versus Field-Based Time
Marcações com uso de tempo incremental ou de tempo field-based afetam de modos diversos a maneira como são processadas certas operações. Por exemplo; marcações que se utilizam de tempo incremental podem ser comparadas diretamente — o valor inteiro da marcação determina qual é o mais cedo e qual é o mais tarde — enquanto que marcações que se utilizam de tempo field based precisam ser normatizadas para que seus campos possam ser comparados. Tempos field based podem estar sujeitos a certas lógicas de operação para poderem ser processados ( por exemplo, adiantar ou atrasar a data), ao passo que tempo incremental requer transformações lógicas. Por exemplo; para ajustar a data em um dia adiantado em relação a 2005-08-30, uma implementação poderia adicionar 'uma unidade' ao campo do "dia" e ajustar o mês e o ano apropriadamente. Em em marcação incremental uma operação semelhante a esta pode ser feita adicionando à data o valor de 24 horas * 60 minutos * 60 segundos * 1000 millisegundos, o que representa um dia lógico, contudo poderá haver erro quando um dia em particular tiver uns segundos a mais (tal como acontece por ocasião das mudanças para horário de verão).
Os dados tipo SQL para date, time, e timestamp são expressos em valores de tempo field based que independem da diferença horária de zonas. Os dados do tipo timestamp with time zone são equivalentes ao timestamp em SQL e dependentes da diferença horária de zonas. Linguagens de programação, tendem a se valer do uso de tempo incremental e fazer conversões para tempos locais. Bancos de dados devem utilizar tempo incremental ou tempo field based em ambas as versões dependente e independente da diferença horária de zonas em sua extrutura interna. Por exemplo, um banco de dados Oracle 8 trata um campo timestamp como um tempo local.
Como resultado, os usuários não precisam conhecer as diferenças de representação ou até mesmo podem criar uma mistura de representações. Por exemplo, um programador Java usando JDBC recupera tempo incremental (java.util.Date ) de um banco de dados, mesmo que o campo de armazenamento no banco seja um valor (field-based) timestamp.
Em XML Schema, bem como em SQL, datas e tempos são sempre expressos com uso de tempo field-based. A data ou tempo deve expressar a diferença horária para UTC (por exemplo; usando um formato tal como 08:00:00+01:00). UTC é indicado pela letra Z (por exemplo 08:00:00Z). Ou, a diferença horária de zona deve ser completamente omitida.
Mais precisamente, um valor XML Schema para date ou time com diferença horária é field-based/diferença horária dependente e um sem diferença horária é field-based/diferença horária independente.
Se os dois tipos forem usados, a interpretação da diferença horária não está adequadamente especificada em [XML Schema]. Em [XPathFO], a interpretação fica a cargo da implementação e baseia-se em uma diferença horária implícita. Tal diferença horária atualmente pode ser tanto UTC como tempo local. Em XML Schema, a presença ou ausência de diferença horária não deve ser indicação do tipo de dado, por gerar confusão conforme descrito acima. Processamento e comparações devem se basear em dados de tempo e datas devidamente normalizados da forma independente (ou dependente) de diferenças horárias e nunca misturar as duas formas em uma mesma aplicação em particular.
1.4 Diretrizes
Esta seção descreve diretrizes a serem aplicadas as diversas comparações de datas e tempos.
1.4.1 Trabalhando em XML Schema com datas e tempos Field-Based
Valores de datas e horas field-based implicam em que o usuário determine uma zona fixa de referência para a diferença horária, ou uma zona horária, ou nenhuma delas. Enquanto tempos em XML Schema são field-based em termos de repressentação léxica, tanto os dados em si, quanto a implementação que processa valores podem usar tempo incremental. Cada caso específico deve ser tratado de maneira peculiar.
-
Se todos os valores dos dados são usados em representação de tempo incremental, então o usuário deverá sempre usar uma zona específica de referência (UTC é fortemente recomendada uma vez que a maioria dos sistemas baseia-se nesta zona) Valores que não especificam uma zona de diferença horária devem ser tratados como se tivessem usando uma mesma diferença horátia . Se UTC for usada, causará menos modificação nos dados.
-
Se todos os valores dos dados são usados em representação de tempo independentes da zona (tal como uma listagem de datas de aniversário dos empregados), então a diferença horária deverá sempre ser omitida. Todos os valores que tenham uma diferença horária provavelmente devem ignorar a diferença (cortando-a fora sempre que possível) uma vez que mudanças de zona se prestam a outros caminhos de processamento. Caso uma diferença horária deva ser aplicada aos dados, então UTC deverá ser usada.
-
Se todos os valores dos dados são usados em representação de tempo, dependentes da zona, então a diferença horária deve ser fornecida. Tomar cuidado em fornecer a correta diferença horária e não a diferença relativa a zona corrente. Por exemplo, se uma sistema na zona U.S. Pacific (America/Los_Angeles) gera um valor dateTime igual a 2005-02-11T11:23:04-07:00 em 2005-08-16, isto estará errado (uma vez que a diferença horária UTC em agosto naquela zona é UTC-7, porém, em fevereiro é UTC-8).
-
Se forem usados somente valores de tempo (sem data especificada) com um valor fixo de diferença horária para UTC, então a diferença horária deve sempre ser indicada. Isto é, não deve ser usada para uma agenda de eventos em Pacific Time, mas uma agenda em tempo UTC-0800 (e válida para o Pacific Time UTC-0700 em determinadas épocas do ano).
1.4.2 Trabalhando com valores data e hora dependentes de uma zona horária (e não de diferença horária )
Documentos ou sistemas podem também escolher seguir um valor para tempo com um identificador de zona ou usar um tipo complexo de TZID. Isto é muito importante com tempos recorrentes, tais como calendários de agendamentos de encontros. Se um evento está programado para às "08:00 Pacific Time", tal dado é insuficiente para armazenar uma diferença horária para intercâmbio da hora.
Infelizmente data e hora XML Schema não possibilitam o fornecimento de identificadores Olson IDs, assim sendo a maioria destas operações com tempo não podem se valer de TZIDs diretamente. A identificação da data hora em zona horária baseia-se inteiramente em diferença horária para UTC. É da competência do projetista manter a TZID em um campo de dados separado do campo para o valor do tempo.
Existem diversas maneiras de se comparar dois <datetime, TZID>. Se ambas as datas/ horas tiverem um valor fixo (2004-09-31T01:30), então pode-se fazer a comparação pela diferença horária usando o banco de dados para TZ. O ordenamento mostrará qual datetime é (em valor absoluto) anterior.
Se as datas não são fixas (tal como <T01:30, TZID> observe a omissão da data) então não há sentido em data 'anterior', uma vez que ambas se referem a um conjunto interpolado de horas. A forma mais simples de estabelecer uma comparação entre datas não especificadas por completa é a de colocá-las em uma forma canônica e a seguir ordená-las primeiramente pela hora e depois pela TZID (ordem alfabética e contínua ). O banco de dados Olson não mantém uma forma canônica fixa; contudo, CLDR disponibiliza tal forma. (Ver: [CLDR]).
(É possivel estabelecer uma comparação menos rigorosa quando <time0, TZID0> é comparado com <time1, TZID1> em um intervalo de tempo: Se um deles tem uma diferença horária menor durante aquele período de comparação, será considerado anterior. Contudo haverão casos em que tal mecanismo resultará em um ordenamento parcial.
1.4.3 Comparando horários
Conversão ou operação com dados que misturam notação com diferença horária e sem diferença horária apresentam problemas.
<aDateTime>2005-06-07T13:14:27Z</aDateTime> <!-- com diferença horária -->
<bDateTime>2005-06-07T11:00:00</bDateTime> <!-- sem -->
Se alguém quiser fazer uma comparação entre os valores acima <aDateTime> e <bDateTime>, será necessário que os dois valores sejam transformados para uma mesma referência. <aDateTime> usa UTC e pode facilmente ser convertido para computer time ou mesmo para uma outra zona de referência . <bDateTime> não contém qualquer indicação de referência a uma zona. A referência pode ser tanto UTC como uma outra qualquer que não contenha indicação de diferença horária. Pode ser tanto UTC como um valor qualquer (no caso um valor de até 14 horas de diferença UTC para mais ou para menos)
É de boa prática usar sempre que possível, uma zona específica para referência de diferença horária. Não estando disponível tal zona é de boa norma usar UTC como zona implícita para conversões desta natureza. Isto deve-se ao fato de que os valores são baseados em uma faixa exata de possibilidades e ainda porque as representações internas (tais como computer time) normalmente baseiam-se em UTC. Uma vez que foi usado um ponto de referência singelo será possível desfazer as mudanças mais tarde mesmo que tenham sido feitas conversões erradas. Ao se trabalhar com múltiplos documentos provenientes de variadas fontes o significado de "implícito" para diferenças no documento poder variar significativamente em relação aquela da aplicação que esta realizando o processamento. Se UTC for usada, as chances de erro serão reduzidas.
Autores de conteúdos e de consultas devem estar alertas para o fato de que comparar ou processar valores de datas e horários com e sem uma referência de diferença horária pode produzir resultados inesperados e assim, tal procedimento deve ser evitado. Conteúdos gerados com omissão de zona de referência para diferença horária (onde existir tal informação) é uma potencial fonte de erros no futuro. É claro que dados tal como os do tipo SQL já citados anteriormente e que se prestam a representação de wall time devem continuar omitindo a zona de referência para a diferença horária. Autores de consultas podem verificar a existência (ou não existência) de uma zona de referência e devem fazer isto para introduzir modificações em datas e horas explicitamente (em lugar de permitir modificações implícitas) sempre que for possível.
1.5 Recomendações para XQuery / XSLT
Usuários de XQuery 1.0 e XSLT 2.0 e de outras standards deveriam levar em conta as recomendações a seguir, mesmo quando usarem dados sensíveis a zona horária muito raramente. Mais cedo ou mais tarde tais dados serão afetados por um mais itens descritos a segui:
-
Se possível, certifique-se que o dado contenha uma diferença horária explícita.
-
Não aplique operações baseadas em data ou tempo (tal como indexações) em conjunto de dados nos quais alguns itens devem ter informações de diferença horária e outros não.
-
Se os seus dados incluem uma zona de diferença horária fixa e implícita, antes de realizar qualquer operação sensível a data e tempo, a diferença horária para a zona fixa e implícita deve ser ajustada para UTC com uso da função para ajuste da zona de diferença cf. sec. 10.7 in [XPathFO].
-
Se os seus dados contém zona de tempo fixa tanto implícita como explícita e você não deseja ajustar um subconjunto de dados que já possui uma diferença horária, assegure-se de ser capaz de reconhecer tal subconjunto, por exemplo com uso das funções de extração de componentes, cf. sec. 10.5 in [XPathFO].
