As principais dúvidas e dicas sobre como trabalhar com timestamp

Quem já trabalhou com dados de Data e Hora, com certeza já se perguntou: como eu deveria armazenar essa informação? Time Zone e GMT são a mesma coisa? Neste post quero te ajudar a responder as principais dúvidas sobre como trabalhar com timestamp.

O que é timestamp?

Com a tradução direta para “Marca de data e hora”, timestamp é um tipo de dado, cuja pretensão é exatamente marcar com precisão um exato momento no tempo. Mas o tempo está longe de ser um assunto simples.

Por exemplo: digamos que eu deseje armazenar a informação de timestamp atual. Eu teria um dado com a informação de “22/01/2023 12h42m59.456”. Isso dá uma ideia pra você de quando eu estou escrevendo este post. Contudo, essa medida de tempo é relativa ao lugar onde eu estou.

Se ao mesmo tempo eu e alguém no estado do Acre gerarmos um timestamp, nossos relógios teriam 4h de diferença. Pior ainda se estivéssemos na Ilhas Diomedes, onde a diferença é de 21h em uma distância de apenas 4 quilômetros!

Por isso, só a informação de data e hora, pode nem sempre ser suficiente. Para saber o que armazenar, é preciso entender a informação desejada.

Timestamp precisa (ou não) de contexto

Dados precisam de contexto para que gerem uma informação. Desta forma, apenas o texto “22/01/2023 12h42m59.456” não me fornece muito contexto, sendo apenas um dado cru. O que não quer dizer que seja inútil. Vejamos:

Digamos que esta data está vinculada a um relatório de vendas, sendo mais específico, quando essa venda foi executada. Ao olhar para essa data, eu vejo que ela foi efetuada em um domingo, na hora do almoço. Eu conseguiria dizer o mesmo de toda e qualquer venda em qualquer lugar do planeta.

Mas se na China, no Brasil e no Hawaii eu tiver vendas com a mesmíssima estampa de data e hora, isso jamais vai querer dizer que as vendas aconteceram no mesmo momento universalmente. Esse é um caso em que o contexto da informação precisa ser considerado. Já não me interessa o contexto “local” dessa informação, mas sim o contexto “universal” dela.

O que é timestamp local?

Timestamp local diz respeito ao lugar onde o fato registrado ocorreu, não importando o horário universal. Você não precisa – e talvez não deveria – anotar informações como time zone, UTC offset e afins para este tipo de dado, já que ele sempre será considerado “Local” e preferencialmente não seria traduzível para outras geolocalidades.

O melhor cenário para utilizar o timestamp local é quando você precisa construir correlações com outros lugares. Digamos que a sua indústria tem 4 turnos de seis horas e você quer comparar a produtividade de todas as fábricas. Neste caso, o que importa é o tempo local. O que você precisa comparar é a produtividade do turno da “Meia-noite” tanto em São Paulo, quanto no Himalaia.

Relatórios com essa amplitude vão precisar de um tempo para serem concluídos. Afinal, enquanto em São Paulo, estaríamos iniciando o terceiro turno, no Acre o segundo turno ainda estaria em curso. Por motivos como esse, tais relatórios tendem a apresentar apenas informações de D-1 (ontem pra trás).

O que é timestamp UTC

Universal Time Coordinated (tempo coordenado universal) é a nomenclatura que, em 1972, substituiu o GMT (Greenwich Mean Time), mas mantendo o princípio do funcionamento. Ou seja: partindo do fuso que cruza a cidade de Greenwich, você tem um decréscimo de horas, conforme avança à direta do mapa, e um acréscimo de horas conforme vai à esquerda. O horário de Brasília é -3h em relação a Greenwich, portanto UTC-0300.

800px-World_Time_Zones_Map.png (800×431) (wikimedia.org)

Quando falamos em armazenar a data em formato UTC, em geral nos referimos em armazenar o momento zero dessa hora. Ainda com o nosso exemplo, em UTC+0, nosso timestamp seria de “22/01/2023 15h42m59.456+0000”, onde o +0000 é um offset contendo a diferença em relação ao UTC.

Nos fazemos uso desse tipo de dado quando queremos saber o momento no tempo. Eu poderia tirar um relatório das vendas feitas na última hora. Se a informação de referência for UTC+0, o meu resultado vai trazer os dados globalmente. Por outro lado, se a referência for Local, o meu resultado será apenas da produção feita no mesmo fuso em que estou ou à direita dele no mapa.

UTC, Time zone e hora local

Pode ser que, por algum motivo, você deseja mostrar o seu dado armazenado como UTC como hora local. Casos como esse se dão quando, por exemplo, você no Brasil está lendo um relatório enquanto fala com alguém em Los Angeles. E precisa dizer quando a informação aconteceu lá em Los Angeles. Neste caso, você precisa adicionar um pouco mais de contexto a sua informação, para então voltar ao seu estado local.

Fazer a conversão de UTC para Local pode ser perigoso. Ainda que guardar o offset possa ser a primeira solução, ela infelizmente não acrescenta informações de contexto importantes, como as regras para o horário de verão. Ainda tomando a nossa data de exemplo, se eu quiser voltar no tempo com ela para 2019, eu posso ter uma conversão equivocada, já que em 2019 o Brasil tinha horário de verão e em 2023 não temos mais. O UTC+0 de 21/01/2013 12h52 seria 21/01/2023 16h52.

Ao armazenar datas em UTC+0, em que você pode necessitar fazer essa conversão, atente-se em gravar o Time Zone e não apenas o offset do UTC. Você terá informações de contexto muito mais relevantes. E para saber mais sobre Time Zones, dê uma conferida no site da IANA.org (https://www.iana.org/time-zones).

Time Zone e o problema com o futuro

A essa altura, você já deve ter percebido duas coisas: trabalhar com datas não é mesmo simples e que data e hora estão mais atreladas as questões políticas do que físicas. Mas também deve ter percebido que falamos apenas de eventos passados. E os eventos que ainda vão ocorrer? Existe alguma diferença relevante?

A resposta é sim. Time Zone é um banco de dados, mantido pela iana.org, cuja finalidade é ser atualizado conforme as leis dos países sobre a hora local são alteradas. Desta forma, um dado de timestamp gerado ANTES de uma atualização do banco de dados de Time Zone pode gerar efeitos inesperados, como o atraso ou adiantamento de alguma rotina.

Provavelmente isso aconteceu com muitos softwares no Brasil, após a suspensão do horário de verão no país no final de abril de 2019. Qualquer despertador, configurado, no início daquele ano, em UTC+0 para 31/12/2019 23h59, pode ter despertado uma hora antes. Desta forma, um cronjob para geração de ETL pode ter dispensado 1h do funcionamento de uma rede de comércio eletrônico.

Definir o Time Zone e o contexto do seu ambiente

Esta é outra questão que, por vezes, é menosprezada pelas pessoas desenvolvedoras e o pessoal de infra. Um simples DateTime.Now pode causar vários problemas. Afinal, onde está o computador? Qual o Time Zone configurado nele?  Se você está em Dubai, manipulando dados de uma loja em São Paulo, e o servidor está em Paris a instrução DateTime.Now deveria trazer qual informação?

Alinhar o Time Zone

A primeira medida é definir um único Time Zone para todo o ambiente. Sinceramente? Não importa qual seja, desde que sempre seja o mesmo. Honestamente? Prefira deixar todo o seu ambiente como ETC/Utc. Assim você conseguirá ter um feedback visual do que está sendo gravado corretamente em UTC ou não.

Para imagens Docker, você pode utilizar a variável de ambiente “TZ”, definindo seu valor para “ETC/Utc”. Ou pode fazer “na mão”, reescrevendo as configurações do sistema, criando um symbolic link para a informação de TMZ desejada

ln -snf /usr/share/zoneinfo/Etc/UTC /etc/localtime && echo Etc/UTC > /etc/timezone

Utilizar um DateTime Provider

Criar um provider pode ajudar nos testes de unidade que envolvam verificações de data e hora. Mas também vai ajudar bastante na resolução da hora local. Se o seu backend atende diversos Time Zones, pode ser importante sempre tratar o Now como a data local do contexto a que se refere aquela transação.

Digamos que você está no Japão, registrando informações numa filial no Brasil. Evidente que todo o contexto das informações SEMPRE deve considerar a hora no Brasil e não no Japão. Por esse motivo, ter um provider de timestamp pode forçar o timezone como uma regra de negócio para suas aplicações.

O artigo já ficou muito extenso, então é hora de parar por aqui. Mas eu fiquei curioso: Se você tiver um tempinho, bem que podia deixar aqui nos comentários alguma dúvida ou dica que eu deixei escapar. Você me faria este favor?

Deixe um comentário

O seu endereço de e-mail não será publicado. Campos obrigatórios são marcados com *

Esse site utiliza o Akismet para reduzir spam. Aprenda como seus dados de comentários são processados.