Artigo
Timestamps Unix e expressões cron explicados
Um timestamp Unix é apenas um inteiro. Uma expressão cron é apenas cinco campos. Ambos aparecem constantemente no trabalho de backend, e ambos pegam as pessoas de surpresa de formas previsíveis: um por causa dos fusos horários, o outro por causa da unidade.
O que é um timestamp Unix
Um timestamp Unix conta o número de segundos decorridos desde 1970-01-01 00:00:00 UTC, um ponto de referência conhecido como epoch Unix. Essa definição tem duas consequências importantes. Primeiro, a contagem é em UTC: não há fuso horário embutido no número em si. 1718400000 significa o mesmo instante em qualquer lugar da Terra, independentemente de onde a máquina que o armazena esteja. Segundo, o epoch é definido em segundos, não em qualquer outra unidade. Um valor como 1718400000 é sempre segundos desde meia-noite de 1 de janeiro de 1970 UTC, a menos que um sistema ou protocolo tenha feito uma escolha diferente explicitamente. Os timestamps são livres de fuso horário por design, o que é exatamente o motivo pelo qual são úteis para logs, bancos de dados e comunicação entre sistemas em que relógios de diferentes regiões devem se referir ao mesmo momento de forma inequívoca.
Segundos, milissegundos e o problema do ano 2038
Muitos runtimes e APIs modernos usam milissegundos em vez de segundos. O Date.now() do JavaScript retorna milissegundos, então 1718400000000 é o mesmo instante que o valor de precisão de segundo 1718400000. Quando você recebe um timestamp desconhecido, a magnitude diz a unidade: um número de 10 dígitos é quase sempre segundos; um número de 13 dígitos é quase sempre milissegundos. O problema do ano 2038 surge de uma escolha diferente: armazenar um timestamp de precisão de segundo em um inteiro com sinal de 32-bit. O valor máximo de um inteiro com sinal de 32-bit é 2147483647, que corresponde a 2038-01-19 03:14:07 UTC. Depois desse segundo, o contador estoura para um número negativo grande e a data retrocede para 1901 em sistemas que não tratam o limite. A correção é usar armazenamento de 64-bit. A maioria dos sistemas operacionais e bancos de dados atuais já o fazem, mas sistemas embarcados, dispositivos de rede e formatos de arquivo antigos que fixaram a largura do campo décadas atrás ainda estão em risco.
Convertendo epoch para data legível: a etapa do fuso horário
Converter um valor de epoch para uma data legível requer dois passos: recuperar os componentes da data UTC a partir do inteiro e, em seguida, aplicar um offset UTC para obter o horário local. O timestamp em si está em UTC. Quando você pergunta que data 1718325000 representa, a resposta correta é 2024-06-14 às 00:30 em UTC. Em Nova York (UTC-4 no verão), esse mesmo segundo cai em 2024-06-13 às 20:30 da noite anterior: a data muda, não apenas a hora. Esta é a etapa que produz resultados errados quando ignorada: um desenvolvedor registra o timestamp bruto em UTC, uma ferramenta de relatório o renderiza em horário local sem conversão, e a data parece estar errada por horas ou um dia inteiro. A ferramenta de conversor de timestamp do Sunasty lida com isso explicitamente: você insere um valor de epoch e ela mostra a data e hora em UTC ao lado da data e hora locais do seu próprio dispositivo, para que uma mudança de dia como essa fique visível de imediato. A conversão funciona inteiramente no navegador e nada que você colar é enviado.
Sintaxe cron: cinco campos, intervalos, passos e listas
Uma expressão cron agenda tarefas recorrentes em sistemas do tipo Unix. A sintaxe padrão tem cinco campos separados por espaço: minuto (0-59), hora (0-23), dia do mês (1-31), mês (1-12), dia da semana (0-7, onde 0 e 7 representam domingo). Um asterisco (*) em um campo significa "todo valor válido". A expressão 30 8 * * 1-5 é executada às 08:30 de segunda a sexta-feira. Intervalos usam hífen: 1-5 cobre os valores 1, 2, 3, 4, 5. Listas usam vírgulas: 1,15 significa o 1º e o 15º. Passos usam barra: */15 no campo de minuto significa a cada 15 minutos (0, 15, 30, 45). Esses combinadores podem aparecer juntos: 0-30/10 significa 0, 10, 20, 30. Uma coisa que o cron não tem é um campo de fuso horário. O daemon lê o relógio da máquina em que está rodando, que está definido para o fuso horário local do servidor. Se o servidor usa UTC, mas o desenvolvedor espera horário local, a tarefa dispara na hora errada do relógio. A regra prática é tratar os agendamentos cron como expressões no horário local do servidor e documentar o fuso horário do servidor ao lado da linha cron.
Usando o conversor de timestamp localmente
O conversor de timestamp do Sunasty converte nas duas direções: epoch para data legível e data legível de volta para epoch. Você pode inserir um valor de precisão de segundo ou de milissegundo; a ferramenta detecta a unidade pela magnitude. Ela mostra o resultado em UTC e no fuso horário local do seu próprio dispositivo lado a lado, junto com os valores brutos em segundos e milissegundos prontos para copiar. Um botão Agora preenche o timestamp atual com um clique, o que é uma forma rápida de checar o horário Unix atual sem abrir um terminal. Não há um seletor de fuso horário separado: a coluna local sempre reflete o fuso horário configurado atualmente no seu navegador. Tudo isso funciona no navegador. O valor que você cola no campo é lido pelo JavaScript do lado do cliente e nunca sai do dispositivo.
Ferramentas neste artigo
- Conversor de TimestampConverta timestamps Unix para datas legíveis (UTC + local) e vice-versa. Detecta automaticamente segundos versus milissegundos.
- Diferença entre datasConte os dias, semanas, meses e anos entre duas datas, inteiramente no seu navegador, nada enviado.
- Analisador de expressão cronAnalise uma expressão cron e visualize os próximos horários de execução. Privado, no navegador.
Perguntas frequentes
Por que o JavaScript usa milissegundos em vez de segundos?
O objeto Date do JavaScript foi projetado para trabalhar com precisão de subfração de segundo desde o início, e os milissegundos fornecem mil vezes a resolução dos segundos sem exigir um ponto decimal. A troca é que os valores são maiores, o que é por isso que Date.now() produz um número de 13 dígitos enquanto a maioria dos timestamps do lado do servidor tem 10 dígitos.
Todo servidor que roda cron precisa estar em UTC?
Não, mas rodar servidores em UTC é uma prática comum precisamente porque remove a ambiguidade. Quando um servidor está em UTC, uma expressão cron como 0 2 * * * significa 02:00 UTC e esse horário é estável o ano todo. Em um servidor em uma zona que observa o horário de verão, a mesma tarefa dispara em um instante UTC diferente no verão e no inverno, e pode disparar duas vezes ou pular uma vez na mudança de relógio.
Qual é o tipo de armazenamento seguro para timestamps após 2038?
Um inteiro com sinal de 64-bit armazena timestamps de precisão de segundo até o ano 292277026596, o que está bem além de qualquer preocupação prática. A maioria dos bancos de dados atuais armazena timestamps como valores de 64-bit por padrão. Se você está trabalhando com um esquema legado ou um formato de arquivo binário que usa campos de 32-bit, migrar para armazenamento de 64-bit antes do limite de 2038 é a correção correta.