Trabalhando com Fusos Horários
Date e Timestamp
Talvez algumas pessoas tenham um conceito errado sobre Timestamp e Date. Alguns podem pensar que a diferença dos dois é que o Timstamp adiciona a informação de fuso horário em relação ao tipo Date. Mas isso não é verdade. Esse tipo de erro é mais comum acontecer entre desenvolvedores. A única diferença entre ambos é que o Timestamp adiciona fração de segundos para um tempo mais preciso e só, conforme podemos ver mais a baixo:
Fuso Horário
Bem, todos nós entendemos o conceito do fuso horário e sabemos que a hora difere em diferentes partes do mundo em um dado momento. E para entendermos como o Oracle trabalha com essas situações, devemos saber a definição de 3 fusos horários descritos a seguir:
- UTC – Padrão Universal, antigamente conhecido com o horário de Greenwich. Tem o fuso horário +-00:00 e todos os outros fusos horários se baseiam nele.
- Fuso Horário do Banco de Dados – Fuso horário de onde o banco de dados está instalado.
- Fuso Horário da Seção – Fuso horário do usuário que está acessando o banco de dados.
A recomendação da Oracle é que o fuso horário do banco de dados seja o UTC, pois assim simplifica todo o processo de trabalho com fusos horários diferentes e até mesmo agilizamos o processo, pois eliminamos a compensação do fuso.
Tipos de Dados com Fuso Horário
Existem dois tipos de dados no Oracle que podemos trabalhar com fuso horário. O TIMESTAMP WITH TIME ZONE e o TIMESTAMP WITH LOCAL TIME ZONE. Esses dois tipos de dados trabalham de maneira diferentes relaltivo ao fuso horário. O TIMESTAMP WITH TIME ZONE armazena tudo o que um Timestamp tem mais o fuso horário, já o TIMESTAMP WITH LOCAL TIME ZONE não armazena o fuso horário e sim a data normalizada no horário UTC, então quando for feita uma query nessa data ela será apresentada no horário local do usuário.
Então via de regra seria, se para a aplicação precisa saber em qual fuso horário aquele registro foi feito, então devemos utilizar o TIMESTAMP WITH TIME ZONE. Caso não, ou seja, mesmo que a a plicação rode em diversos locais no mundo, mas desejamos sempre ver o registro no horário local, independente de onde foi feito o INSERT, devemos utilizar o TIMESTAMP WITH LOCAL TIME ZONE. .
Alem da notação pela diferença explícita em relação ao UTC, como no caso de -03:00(TZH:TZM), temos também o nome da região do fuso horário e a sua abreviação. Podemos verificar essa lista inteira direto no banco realizando a query abaixo:
Muitas vezes é melhor utilizarmos o nome da região por que o horário de verão pode entrar em vigor de forma automática, na qual é a recomendação da Oracle
Funções de Tempo
Vejamos agora algumas funções em que podemos trabalhar com fusos horários, vejam as primeiras logo abaixo.
Ambas as funções retornam APENAS o fuso horário e mais nenhuma outra informação. Podemos perceber o fuso horário do banco e da minha seção. Veja como diferem. O do banco está com o fuso horário UTC, +-00:00, conforme a própria recomendação da Oracle. E o meu fuso horário esta com o horário de Brasília.
Vejam agora mais duas funções. A CURRENT_DATE, que não recebe nenhum parâmetro e nos retorna a data com o horário da sessão do usuário. Já a função CURRENT_TIMESTAMP, nos retorna a mesma coisa que a função anterior, mas adiciona as frações de segundos juntamente com o fuso horário da sessão atual, ou seja, um TIMESTAMP WITH TIME ZONE. Essa segunda função recebe um argumento opcional, que é um número de 1 a 9, caso seja omitido será utilizado o número 6 como padrão. Esse argumento se refere a precisão que podemos ver na foto acima.
A função LOCALTIMESTAMP, que já vimos no início do artigo, retorna apenas o TIMESTAMP sem o fuso horário, adicionando apenas as frações de segundos que não existe no tipo DATE. Também recebe um argumento opcional referente a precisão das frações de segundos como vimos na função anterior. Já a função SYSTIMESTAMP é um TIMESTAMP WITH TIME ZONE com o horário do banco de dados, que geralmente é o horário UTC.
Bem, essas foram as funções que nos retornam basicamente apenas informações. Vejamos agora funções que nos ajudam a trabalhar com essas informações.
A primeira função da imagem acima, a NEW_TIME, transforma o primeiro argumento que é um DATE em outro DATE mas com horários diferentes baseados nos outros dois argumentos que são fusos horários. É assumido que o primeiro fuso horário é referente ao DATE passado como argumento, e assim transformamos a hora em um fuso horário diferente utilizando o terceiro argumento. Já a segunda função, a FROM_TZ, recebe um TIMESTAMP e nos retorna um TIMESTAMP WITH TIME ZONE utilizando o segundo argumento da função, que tanto pode ser na forma TZH:TZM como foi utilizado, como também a abreviação que foi utilizado na função NEW_TIME.
A função TO_TIMESTAMP_TZ recebe 3 argumentos como parâmetros, apenas o primeiro é obrigatório. O primeiro parâmetro é um CHAR que define o nosso TIMESTAMP o segundo é o formato do TIMESTAMP, e caso seja omitido o primeiro argumento tem que estar no formato padrão de um TIMESTAMP. o Terceiro parâmetro que não utilizamos é referente a nls_params.
A função CAST é bem útil, pois podemos transformar uma representação de caracteres em um formato desejado. No caso acima transformamos em 3 formatos diferentes, demonstrando a versatilidade dessa função
A primeira função a EXTRACT extrai informações do nosso segundo argumento. O primeiro argumento pode ser um dos seguintes: YEAR, MONTH, DAY, HOUR, MINUTE, SECOND, TIMEZONE_HOUR, TIMEZONE_MINUTE, TIMEZONE_REGION, TIMEZONE_ABBR. Já a função SYS_EXTRACT_UTC transforma o argumento em um TIMESTAMP com o horário de UTC.
Nessa nossa ultima imagem vemos as nossas duas últimas funções discutidas aqui. Ambas as funções apenas altera o fuso horário, bem similiar a outras funções. Podemos tanto usar no formato TZH:TZM como as abreviações. A segunda e ultima função é a AT LOCAL. Ela converte o argumento passado para o fuso horário da sessão.
Neste meu primeiro post você viu uma pequena expliação de como podemos trabalhar com fuso horários de maneiras práticas. As vezes podemos nos confundir um pouco referente a tantas funções com os seus parâmetros e resultados. Mas devemos estar bem familiarizados com o conteúdo do que foi explanado aqui caso desejamos tirar uma certificação como a Oracle SQL Expert
Referência
- Livro – OCA Oracle Database SQL Certified Expert Exam Guide (Exam 1Z0-047), Steve O’Hearn – Oracle Press – Mc Graw Hill
- Wikipédia – http://pt.wikipedia.org/wiki/UTC%2B0
Abraço
