Conversor de timestamp Unix

Contar os dígitos

A única parte verdadeiramente complicada de ler uma marca temporal é descobrir a sua unidade, e a ordem de grandeza resolve isso. Na prática não há ambiguidade, porque as gamas não se sobrepõem para nenhuma data com que alguém trabalhe de facto.

Enganar-se aqui é falhar por um factor de mil, portanto o resultado cai ou no início dos anos 1970 ou dezenas de milhares de anos no futuro. Evidente quando se olha; totalmente invisível quando é uma coluna numa tabela de registos — e é aí que morde de facto.

O que o tempo Unix conta realmente

Segundos desde as 00:00:00 UTC de 1 de Janeiro de 1970, assumindo que cada dia dura exactamente 86 400 segundos.

Essa premissa é falsa. De poucos em poucos anos inserem-se segundos intercalares para manter o tempo atómico alinhado com a rotação da Terra, que vai abrandando. O tempo Unix não os representa — os sistemas repetem um segundo, ou diluem-no ao longo de um dia, para que a contagem se mantenha uniforme.

A consequência é que o tempo Unix não é uma contagem verdadeira dos segundos decorridos desde 1970; está uns vinte e sete segundos atrasado. Para agendamento, registo e prazos de validade essa é exactamente a troca certa, porque a aritmética uniforme importa mais do que a exactidão astronómica. Para medir duração realmente decorrida, use antes um relógio monótono — o relógio de parede também pode saltar para trás quando o NTP o corrige.

O problema de 2038

Um inteiro de 32 bits com sinal guarda até 2 147 483 647, o que como marca temporal Unix corresponde às 03:14:07 UTC de 19 de Janeiro de 2038. Um segundo depois transborda para negativo e a data passa a Dezembro de 1901.

Tudo o que é moderno usa 64 bits e chega para uns 292 mil milhões de anos. O que não é moderno: firmware embebido, controladores industriais, alguns tipos de coluna de bases de dados mais antigos e código C que ainda assume um time_t de 32 bits. Os sistemas em maior risco são aqueles para os quais ninguém está a olhar, que foi o que tornou o Y2K caro também.

Que formato usar de facto

ISO 8601 em UTC, para tudo o que atravesse uma fronteira entre sistemas ou seja lido por uma pessoa:

2026-08-27T14:30:00Z

É inequívoco, ordena correctamente como texto simples e é legível num registo às duas da manhã. O Z importa: sem ele, a maioria dos analisadores assume hora local, e acabou de inventar um defeito que só se manifesta para utilizadores noutros países.

Os segundos Unix servem internamente — são o que as reivindicações exp e iat dos JWT usam, e comparar inteiros é barato. O custo é serem ilegíveis e convidarem à confusão de unidades acima.

A evitar: qualquer formato com desvio mas sem identificador de zona (+01:00 não lhe diz se é BST ou CET, o que importa para datas futuras), e tudo o que caia no território do 03/04/2026, que significa dois dias diferentes conforme o lado do Atlântico em que o lê.

Guardar eventos futuros

Uma subtileza que apanha as pessoas. Para uma reunião às 09:00 em Março do próximo ano, guardar UTC está errado — se as regras de fusos horários mudarem daqui até lá, e os governos mudam-nas, a reunião muda de hora. Os eventos locais futuros devem ser guardados como hora local mais um identificador de zona (Europe/London) e convertidos no momento da apresentação com as regras então em vigor. Com os eventos passados é o contrário: UTC, porque o que aconteceu está fixado.

Relacionado

As reivindicações exp e iat dos JWT são segundos Unix — o descodificador de JWT converte-as por si e assinala a expiração. Se se trata de agendar em vez de converter, o analisador de cron mostra quando um agendamento dispara a seguir.