Unix time representa um instante como a quantidade de unidades desde o início de 1970 em UTC. A ideia permite comparar eventos sem carregar idioma, nome do mês ou timezone em cada valor. Timestamps expiram tokens, ordenam logs, executam jobs e registram auditoria. O número, porém, não resolve sozinho os problemas do tempo. Unidade, precisão, qualidade do relógio e intenção humana continuam sendo decisões.

Instante não é data formatada

Um timestamp aponta para uma posição na linha do tempo. Ele não contém a forma de exibição. O mesmo instante pode aparecer como noite em um país e manhã do dia seguinte em outro.

Guardar um instant UTC e formatar no locale do usuário é saudável. O erro acontece quando um horário local é tratado como se já tivesse um significado global.

Segundos e milissegundos se confundem

Unix clássico conta segundos. JavaScript e muitas APIs contam milissegundos. Interpretar a unidade errada leva a 1970 ou a um futuro distante.

Campos devem nomear a unidade ou usar um formato explícito. Adivinhar pelo número de dígitos serve para diagnóstico, não para contrato.

O relógio da máquina é uma medição

Relógios derivam, sincronizam e podem saltar. Wall clock é adequado para registrar quando algo ocorreu. Ele é perigoso para medir duração porque pode voltar.

Timeouts e elapsed time precisam de monotonic clock. Esse relógio não representa calendário, mas avança de forma consistente no processo.

Leap seconds mostram a complexidade

O tempo civil ocasionalmente precisou acomodar segundos extras. Implementações Unix podem repetir, suavizar ou seguir comportamento específico da plataforma.

A maioria das aplicações pode confiar na plataforma. Sistemas científicos e financeiros de alta precisão precisam entender fonte e política de sincronização.

Precisão precisa ser honesta

Salvar nanossegundos não significa medir com essa precisão. Tipos de banco, floats e formatos externos possuem limites. Sistemas antigos de 32 bits enfrentam o problema de 2038.

O contrato deve informar precisão e regra de arredondamento. Caso contrário, serviços podem ordenar eventos próximos de maneira diferente.

Nem todo conceito temporal é um instant

Criação de pedido é instant. “Todo dia às 9h em São Paulo” é regra local. Aniversário é data de calendário. Cache TTL é duração. Um timestamp não representa corretamente todos esses conceitos.

Eventos recorrentes precisam de local time, regra e timezone IANA. Cada ocorrência futura é calculada com as regras atuais.

Tipos de banco carregam assumptions

Alguns tipos normalizam UTC; outros armazenam wall-clock sem zona. A timezone da sessão do banco pode mudar leitura e escrita.

Documente se a coluna contém instant, local date, local date-time ou duration. Um nome genérico como date não basta.

APIs devem nomear unidade e precisão

Um produtor em microssegundos e consumidor em segundos podem perder ordem. Defina se dígitos extras são rejeitados, arredondados ou truncados. Exemplos devem incluir offset e subsegundos.

Essa mesma política precisa existir em logs, banco e mensagens para evitar conversões silenciosas.

Imports históricos precisam de classificação

Uma coluna antiga pode misturar segundos, milissegundos, strings locais e valores vazios. Converter tudo com uma única regra pode deslocar anos de eventos. Antes da migração, amostre intervalos, identifique produtores e preserve backup.

Validações de faixa ajudam a detectar unidade errada. Uma data de criação no futuro distante ou próxima de 1970 costuma indicar interpretação incorreta.

Timestamp não deve virar ID de ordenação

Dois eventos podem ocorrer na mesma unidade de precisão, e clocks distribuídos podem discordar. Se o sistema exige ordem total, use sequence number, versão ou chave específica além do tempo.

O timestamp continua útil para exibição e análise aproximada. Ele só não deve carregar uma garantia que o relógio não oferece.

Conversão deve preservar origem quando necessário

Para auditoria, pode ser útil guardar o instant normalizado e também o timezone ou texto original enviado pelo usuário. Essa informação explica decisões futuras sem usar a forma original como fonte de verdade.

O modelo deve diferenciar dado canônico e contexto de entrada para não reinterpretar o valor a cada leitura.

Floating point pode perder precisão silenciosamente

Representar segundos com fração em float parece conveniente, mas a precisão binária diminui para valores grandes. Ao serializar e desserializar, microssegundos podem mudar. Inteiros com unidade explícita ou tipos temporais nativos são mais previsíveis.

Se uma API usa decimal textual, produtor e consumidor devem concordar sobre quantidade de casas e arredondamento. Precisão aparente não deve ultrapassar a precisão real do relógio.

Logs precisam ser comparáveis

UTC, formato uniforme, precisão conhecida e trace ID facilitam incidentes distribuídos. Timestamp ajuda a situar, mas não prova causalidade entre serviços.

Para jobs, registre scheduled, enqueue, start e finish. Assim a equipe localiza o atraso.

Unix time é um denominador comum

Ele funciona bem para instantes técnicos. Não substitui timezone, calendário, recorrência ou duração monotônica. O modelo deve começar pelo significado e só depois escolher a representação.

Essa ordem evita bugs que aparecem em mudanças de timezone, correções de relógio e integrações com outras plataformas.