Um usuário de um dos meus aplicativos Laravel SaaS, uma vez enviado por e-mail para dizer que sua data de renovação de assinatura parecia "um pouco generosa". A página de faturamento dizia a ele que seu plano seria renovado em 25 de abril do ano 57123.
O bug demorou embaraçosamente para encontrar porque cada peça individual estava correta. o frontend do React enviou Date.now()- que retorna milissegundos- e o backend do PHP sim date('Y-m-d', $timestamp), que espera segundos. ração 1740470400000 em uma função esperando 1740470400 E você desembarcará cerca de 55.000 anos no futuro. Sem exceção, nenhum aviso, nenhum teste com falha. Apenas um cliente perguntando educadamente se sua assinatura durou realmente até a morte por calor da civilização.
Os carimbos de data e hora parecem o tópico mais chato do software. Eles são realmente uma das fábricas de bugs mais confiáveis que temos: segundos x milissegundos, UTC vs local, transições de DST, o capotamento de 2038. o conversor de carimbo de data/hora no Toolz.dev existe porque cansei de fazer new Date(x * 1000) Em um console do navegador, quarenta vezes por dia. Este guia cobre o que eu verifico agora, na ordem em que o verifico.
tl;dr: Um carimbo de data/hora do UNIX conta segundos desde 1970-01-01T00:00:00 UTC. 10 dígitos = segundos, 13 dígitos = milissegundos- misturá-los coloca suas datas 55.000 anos fora Loja UTC, converter apenas para exibição, usar nomes de zona IANA como
Asia/Dhakaem vez de abreviaturas. Cole qualquer timestamp no conversor de carimbo de data/hora para obter os formulários ISO 8601, RFC 2822, local e UTC - ele executa o lado do cliente, portanto, carimbos de data/hora fora JWTS E os logs de produção nunca saem do seu navegador.
O que é exatamente um timestamp Unix?
Um timestamp do UNIX (tempo de época, tempo POSIX) é o número de segundos decorridos desde 1 de janeiro de 1970, 00:00:00 UTC- o & quot;Unix epoch." It' s um único inteiro, não tem fuso horário (it' s sempre UTC por definição), e efetivamente todo SO, linguagem e banco de dados entende que a última propriedade é por isso que sobreviveu cinco décadas: é o formato único sobre o qual ninguém discute.
Por que 1970? nenhuma razão profunda - era uma data rodada conveniente perto de quando o Unix estava sendo construído no Bell Labs, e o Unix inicial contava o tempo em um número inteiro de 32 bits A escolha arbitrária fossilizou em um padrão universal, que é muito Unix.
Alguns pontos de referência que valem a pena reconhecer à vista:
| registro de data e hora | Data UTC | Por que você veria |
|---|---|---|
0 |
1970-01-01 00:00:00 | A época. também o que você recebe de null/0 bugs - uma data em 1970 na tela quase sempre significa um valor não inicializado, não uma viagem no tempo |
946684800 |
2000-01-01 00:00:00 | y2k |
1234567890 |
2009-02-13 23:31:30 | Os desenvolvedores realmente deram festas para este |
1740470400 |
2025-02-25 08:00:00 | Um carimbo de data e hora moderno comum de 10 dígitos |
2147483647 |
2038-01-19 03:14:07 | O máximo assinado de 32 bits - veja Y2038 abaixo |
Essa quarta linha é meu exemplo favorito por um motivo sutil: muitas listas de páginas de tutorial 1740470400 AS "25 de fevereiro de 2025, 12:00:00." Na verdade, é 08:00 UTC- alguém converteu-o em seu fuso horário local uma vez e o valor errado foi copiado-colado em torno de desde então Verifique carimbos de data/hora com uma ferramenta, não com um post no blog Incluindo este.
Segundos ou milissegundos - como você conta?
Conte os dígitos. Para qualquer data da era atual:
- 10 dígitos (
1740470400) - segundos. Convenção Unix, a maioria das APIs, PHP'stime(), Pythontime.time()(como float), a API da faixa. - 13 dígitos (
1740470400000) - milissegundos. JavaScript'sDate.now(), JavaSystem.currentTimeMillis(), datas do MongoDB.
Esta é a distinção exata que produziu minha data de renovação do ano 57123, então vou explicar os modos de falha:
- MS interpretada como segundos → datas de ~ 55.000 anos no futuro
- Segundos interpretados como MS → Datas em Janeiro de 1970 (Tudo se encaixa dentro de ~ 3 semanas da época)
Se você vir qualquer assinatura - datas antigas ou datas absurdas de um futuro distante - você conhece o bug antes de ler uma linha de código O conversor de carimbo de data/hora Detecta contagem de dígitos e rotula ambas as interpretações, o que acerta o argumento "este S ou ms?" em dois segundos.
Quais formatos de data você realmente precisa saber?
Três cobrem quase tudo que um desenvolvedor que trabalha toca.
ISO 8601- o padrão internacional e o que você deve emitir em APIs e logs:
2026-07-13T09:30:45Z UTC ("Z" = Zulu)
2026-07-13T15:30:45+06:00 with timezone offset
2026-07-13T09:30:45.123Z with milliseconds
O recurso assassino que ninguém menciona: ISO 8601 Strings Ordenar lexicograficamente em ordem cronológica. sort Em um arquivo de log simplesmente funciona. 02/25/2026-formatos de estilo podem't fazer isso - e pior, EUA MM/DD e europeu DD/MM São indistinguíveis durante doze dias de cada mês.
RFC 3339 (especificação) - o perfil do protocolo de internet da ISO 8601. um pouco mais rigoroso; se sua API emitir 2026-07-13T09:30:45Z Você satisfaz os dois. Este é o formato para padronizar.
RFC 2822 (Sun, 13 Jul 2026 09:30:45 +0000) - cabeçalhos de e-mail e HTTP, feeds RSS Você lê com mais frequência do que escreve.
Os formatos de banco de dados são primos próximos: MySQL DATETIME é 2026-07-13 09:30:45 (ISO com um espaço), PostgreSQL timestamptz renders 2026-07-13 09:30:45+00.
Como os idiomas que eu uso lidam com os carimbos de data/hora?
Os três da minha própria pilha - e a peculiaridade de cada um que pessoalmente me custou tempo.
Javascript (o MS):
Math.floor(Date.now() / 1000) // current Unix seconds — Date.now() is ms!
new Date(1740470400 * 1000) // seconds → Date: multiply by 1000
date.toISOString() // "2025-02-25T08:00:00.000Z"
Date.parse('2026-07-13T09:30:45Z') / 1000 // ISO string → Unix seconds
Quirk: tudo é milissegundos, e new Date(1740470400) Silenciosamente, oferece a você 21 de janeiro de 1970 em vez de fevereiro de 2025. nenhum erro. Essa assimetria é o bug mais comum do carimbo de data/hora no desenvolvimento web.
php (o segundo):
time(); // current Unix seconds
date('Y-m-d H:i:s', 1740470400); // "2025-02-25 08:00:00" (server TZ!)
strtotime('2026-07-13 09:30:45'); // string → timestamp
(new DateTime('@1740470400'))
->setTimezone(new DateTimeZone('Asia/Dhaka'))
->format(DateTime::ATOM); // "2025-02-25T14:00:00+06:00"
Quirk: date() formatos no servidor Zona de tempo padrão, portanto, o mesmo código imprime datas diferentes em sua máquina e em produção. Também, new DateTime('@1740470400') ignora qualquer fuso horário que você passar para o construtor - o @ O formulário é sempre UTC; você deve ligar setTimezone() depois. WordPress adiciona sua própria camada: current_time('timestamp') Retorna um falso deslocamento local do timestamp do tempo real do Unix, o que é exatamente tão perigoso quanto parece.
píton:
import time, datetime
int(time.time()) # current Unix seconds
datetime.datetime.fromtimestamp(1740470400,
tz=datetime.timezone.utc) # → aware datetime
dt.isoformat() # "2025-02-25T08:00:00+00:00"
Quirk: fromtimestamp() sem tz= Retorna um DateTime ingênuo na hora local. Os DateTimes ingênuos são o bug do tempo em Python: eles se comparam e subtraem alegremente um contra o outro até o dia em que um deles cruzou um limite de horário de verão. sempre passa tz=; use zoneinfo (stdlib desde 3.9) para zonas nomeadas.
Como você deve lidar com fusos horários sem enlouquecer?
Quatro regras, todos aprenderam o jeito irritante:
- Loja UTC. sempre. selos de data e hora do UNIX ou
timestamptzno banco de dados. O fuso horário torna-se apenas uma preocupação com a exibição. - Converta na camada de apresentação. O usuário em Dhaka vê
+06:00, o usuário em Berlim vê+02:00, o banco de dados não vê nenhum dos dois. - Use nomes IANA, não abreviações.
Asia/Dhaka,America/New_York,Europe/Berlin. As abreviaturas são ambíguas -CSTsignifica Central US, China Standard Time, ou Cuba Standard Time dependendo de quem & #39; s leitura - e abreviaturas don & #39; t codificar regras DST. IANA nomes fazem. - Nunca role a mão lógica DST. As datas de horário de verão são diferentes por país, mudança por legislação e alguns lugares (Arizona, Bangladesh, Japão) não observam o horário de verão. O banco de dados IANA TZ existe porque é realmente difícil; use a biblioteca que o envolve.
O corolário da regra 1: quando dois sistemas discordarem sobre um horário de evento, converta os dois valores em timestamps UTC Unix e compare os números inteiros. Argumentos sobre "mas diz 15:00 aqui" se dissolvem instantaneamente.
Qual é o problema do Y2038 e você deve se importar?
Um número inteiro assinado de 32 bits atinge o máximo em 2,147,483,647. Como selo de data e hora do UNIX, isso é 19 de janeiro de 2038, 03:14:07 UTC. Um segundo depois, o valor fica negativo - até 13 de dezembro de 1901.
Parece distante; é o & #39; t, por dois motivos. Primeiro, ele & #39; está a cerca de 11,5 anos de distância enquanto escrevo isso - bem dentro da vida útil de sistemas embarcados, controladores industriais e daquele serviço legado que ninguém quer tocar. Segundo, futuro As datas atingem o muro mais cedo: um sistema que calcula um cronograma de hipoteca de 15 anos ou um certificado de 20 anos cruzando o prazo de 2038 hoje. mysql TIMESTAMP o tipo de coluna é a armadilha clássica - it's com limite de 32 bits e can' t datas de armazenamento anteriores a 19/01/2038, enquanto DATETIME No mesmo banco de dados está bom.
Você está seguro em 64 bits time_t (qualquer sistema operacional moderno), JavaScript (float64 ms), Python (precisão arbitrária) e PostgreSQL. Você está em risco em sistemas embarcados de 32 bits, antigos TIMESTAMP colunas e código C codificado em hardcode int32_t por tempo. O teste é simples: push 2147483648 (um além do limite) por meio do pipeline e veja o que sai. o conversor de carimbo de data/hora Terá prazer em gerar valores de teste pós-2038.
Onde os timestamps aparecem na depuração real?
expiração do JWT. Tokens carregam iat e exp Reivindicações como UNIX segundos:
{ "sub": "user_8241", "iat": 1783915890, "exp": 1783919490 }
"Por que esse usuário está desconectado?" é respondido convertendo exp. decodificar o token no decodificador jwt e converta a reivindicação - ambas executam o lado do cliente, o que importa porque um token colado é uma credencial ativa (a Guia de privacidade de dados Abrange porque eu me recuso a colocar tokens em ferramentas do lado do servidor).
Correlação de log. Um incidente, três serviços, três formatos: NGINX Logs [13/Jul/2026:09:30:45 +0000], o aplicativo registra ISO 8601, um trabalhador de fila registra segundos de época brutos. Converter tudo em um formato é a etapa zero ao construir uma linha do tempo.
Integração de API. Stripe envia "created": 1740470400 (segundos). Uma API criada por JavaScript envia 1740470400000 (ms).As APIs do Google enviam strings RFC 3339. se você consumir todos os três, a conversão é & #39; t ocasional - it& #39; s constante Formate as cargas úteis no formatador json e converter os campos interessantes.
consultas de intervalo de datas. WHERE created_at >= 1752364800 AND created_at < 1752451200- esse é o dia certo? Converta os dois limites e verifique, em UTC, antes de executar o delete. Relacionado: o Calculadora de diferença de datas Por "quantos dias entre esses dois?", o conversor de fuso horário para a matemática do horário de reunião e o analisador de cron Para "Quando esse cronograma realmente é disparado?".
Perguntas frequentes
O que é um timestamp Unix?
O número de segundos decorridos desde 1 de janeiro de 1970, 00:00:00 UTC (a época Unix), armazenado como um único inteiro It' s timezone-independent por definição - o mesmo instante é o mesmo número em todos os lugares da Terra - e é por isso que it' s o formato de intercâmbio padrão em sistemas operacionais, linguagens e bancos de dados.
Por que alguns timestamps têm 10 dígitos e outros 13?
10 dígitos são segundos (convenção padrão do UNIX, PHP, a maioria das APIs); 13 dígitos são milissegundos (Javascript's Date.now(), Java). Divida por 1.000 para ir de MS a segundos. Confundir as datas de dois turnos, seja ~ 55.000 anos no futuro ou de volta a janeiro de 1970.
Os carimbos de data e hora do UNIX podem representar datas anteriores a 1970?
Sim - os valores negativos contam para trás desde a época. -86400 é 31 de dezembro de 1969. Um carimbo de data e hora assinado de 32 bits chega a 13 de dezembro de 1901. Alguns sistemas e APIs rejeitam os registros de data e hora negativos, portanto, teste antes de confiar neles.
Qual é o problema do Y2038?
estouro de carimbos de data/hora assinados de 32 bits em 2.147.483.647 - 19 de janeiro de 2038, 03:14:07 UTC - encerrando até dezembro de 1901. Os sistemas modernos de 64 bits não são afetados, mas dispositivos incorporados de 32 bits, código C legado e MySQL TIMESTAMP colunas são expostas. Sistemas de computação de futuros datas (hipotecas, certificados) atingem o bug anos antes da chegada de 2038.
Por que meu encontro aparece em janeiro de 1970?
Um carimbo de data/hora zero ou quase zero atingiu seu código de formatação - geralmente um valor não inicializado, uma análise com falha retornando 0 ou segundos passados onde milissegundos eram esperados. Uma data de 1970 na tela quase nunca é um ponto de dados; é & #39; é um nulo vestindo uma fantasia.
Devo armazenar os timestamps ou as strings de data e hora no meu banco de dados?
Armazene UTC de qualquer maneira - o tipo importa menos do que a disciplina de fuso horário Os inteiros Unix são compactos, classificam trivialmente e se esquivam da análise inteiramente; timestamptz/DATETIME colunas são legíveis por humanos em resultados de consulta e aritmética de data de suporte em SQL O que você não deve fazer é armazenar horários locais sem deslocamentos - que & #39; s perda de dados que você só descobre na próxima transição DST.
A época é afetada por segundos bissextos?
Praticamente não. O tempo Unix finge que os segundos bissextos não existem - cada dia dura exatamente 86.400 segundos, e os sistemas normalmente mancham ou pisam o relógio quando ocorre um segundo bissexto. Para o código do aplicativo, isso não é problema; só importa em contextos de temporização científica, onde o tempo TAI ou GPS é usado.
É seguro colar os registros de data e hora do registro de produção em um conversor online?
Um carimbo de data/hora bruto por si só revela pouco, mas os carimbos de data/hora geralmente viajam com contexto - IDs de usuário, reivindicações de token, linhas de log. O conversor de carimbo de data/hora No Toolz.dev converte inteiramente em seu navegador sem dados transmitidos, portanto, colar valores diretamente dos logs de produção ou JWTS não expõe nada.
Como faço para converter um timestamp do Unix em uma data legível?
Cole o número em um conversor e leia o UTC e os resultados locais, ou faça isso no código: new Date(ts * 1000).toISOString() Em JavaScript, datetime.fromtimestamp(ts, tz=timezone.utc) Em Python, date -u -d @ts no Linux. a única coisa a acertar primeiro é se o seu valor está em segundos ou milissegundos - tudo o mais segue disso.
Como faço para obter o carimbo de data/hora do Unix atual?
date +%s Em uma concha, Math.floor(Date.now() / 1000) Em JavaScript, int(time.time()) Em Python, SELECT EXTRACT(EPOCH FROM NOW()) No PostgreSQL. Observe que o JavaScript é o estranho: Date.now() Retorna milissegundos, portanto a divisão não é opcional.
