Quase todo timestamp que você já viu em um arquivo de log, uma linha de banco de dados ou uma resposta de API é, por baixo, a mesma coisa: uma contagem de segundos. O tempo é o número de segundos decorridos desde 1970-01-01T00:00:00Z, um momento conhecido como época (epoch).

Um número, sem fuso horário

A característica definidora do tempo Unix é que ele é um único inteiro sem fuso horário anexado. O instante "1700000000" é o mesmo em todo lugar da Terra; o fuso só entra na história quando você quer exibi-lo para um humano. É exatamente essa propriedade que o torna tão usado: dois sistemas em lados opostos do mundo podem comparar, ordenar e armazenar timestamps sem nunca negociar um fuso. Um número maior é sempre mais tarde; a subtração dá uma duração em segundos.

Antes da época

O tempo não começou em 1970, então o tempo Unix simplesmente fica negativo para momentos anteriores. -86400 é exatamente um dia antes da época, 1969-12-31T00:00:00Z. A maioria dos sistemas lida bem com timestamps negativos, embora código mais antigo às vezes assumisse que o tempo era sem sinal e quebre antes de 1970.

Converter para data é aritmética

Transformar um timestamp Unix em uma data de calendário não precisa de relógio nem de rede — é pura aritmética sobre o calendário gregoriano proléptico. Você divide e tira o resto de segundos até dias, considera os anos bissextos e chega a um ano, mês, dia e hora. Como as regras são fixas, o mesmo timestamp sempre produz a mesma data, o que permite que um conversor como este rode inteiramente no seu navegador e gere uma saída idêntica todas as vezes.

Por que venceu

O tempo Unix venceu as alternativas por razões tediosamente práticas: é compacto (um número), trivialmente comparável, irrelevante lexicalmente (sem análise de strings para comparar dois instantes) e inequívoco (sem "isto é 15h em Londres ou em Tóquio?"). O custo é que o número bruto é ilegível para humanos — 1700000000 não significa nada à primeira vista — que é toda a razão pela qual formatos de data e conversores existem.

Vale conhecer duas sutilezas antes de confiar em um timestamp bruto: em qual unidade ele está (segundos, milissegundos ou menor) e o fato de que o tempo Unix silenciosamente ignora os segundos bissextos. Ambos têm seus próprios artigos.

Esta série, em ordem

Este artigo abre a série Como os computadores contam o tempo. O inteiro acima é onde todo timestamp começa; as partes o seguem para fora: as unidades que ele esconde, os segundos bissextos que pula, o ano em que um contador de 32 bits se esgota, os formatos de texto em que é escrito e a aritmética que os fusos horários tornam desonesta.

  1. Segundos, milissegundos, microssegundos, nanossegundos: como distinguir unidades de época. Segundos, milissegundos, microssegundos ou nanossegundos: como distingui-los pelo tamanho do número.
  2. Por que o tempo Unix ignora os segundos bissextos. Por que o tempo Unix finge que todo dia tem 86.400 segundos, e por que essa é a troca certa para o tempo civil.
  3. O problema do ano 2038. O segundo em que um contador de 32 bits com sinal transborda, 2038-01-19T03:14:07Z, e por que a correção é apenas um inteiro maior.
  4. ISO 8601, RFC 3339 e a Data HTTP. O padrão amplo, seu perfil estrito para a internet e a data HTTP, os formatos em que um timestamp volta a ser escrito.
  5. Aritmética de tempo e fusos horários: durações exatas, reuniões honestas. Por que mais um mês não tem resposta exata, o que as durações ISO 8601 prometem e a armadilha do horário de verão.