Um timestamp Unix não é calculado: é lido. O inteiro já contém o instante, e o trabalho é lê-lo de volta como uma data que o olho pode usar. O Conversor de Timestamp Unix faz essa leitura nos dois sentidos. Digite 1.789.689.600 no modo de timestamp para data e o bloco de resultados lê o mesmo instante de seis formas: uma linha ISO, uma linha UTC, uma linha local, uma linha legível, uma linha de data e uma linha de hora, e juntas fixam o instante na sexta-feira, 18 de setembro de 2026, às 00:00 UTC. O modo inverso toma uma data e uma hora tal como um relógio de parede as mostra e devolve o inteiro em segundos e em milissegundos. Uma linha viva no topo da página conta o timestamp atual em segundos, atualizada uma vez por segundo, e cada linha de volta e cada saída tem seu próprio botão de copiar, de modo que o inteiro ou o texto sai do navegador em uma única colagem.
O artigo avança nesta ordem: a origem e a unidade que o inteiro conta; as seis linhas de volta do modo de timestamp para data; a leitura em hora local do modo inverso; a regra de dígitos que decide segundos ou milissegundos; o mesmo instante lido em dois relógios em dois fusos horários; e os lugares para onde o inteiro viaja fora do navegador.
A origem e a unidade que o inteiro conta
O inteiro conta segundos decorridos desde uma origem fixa: 1 de janeiro de 1970 às 00:00:00 UTC, a época Unix. O número 0 é a própria época, os inteiros negativos leem o tempo anterior, e cada dia civil soma exatamente 86.400 à contagem; o contador não insere segundos bissextos, então a aritmética permanece linear. 1.789.689.600 são 20.714 dias depois da origem: 86.400 vezes 20.714 cai exatamente sobre esse inteiro sem resto, por isso a leitura cai na meia-noite limpa de 18 de setembro de 2026 em UTC. O mesmo instante tem uma segunda escrita, a de milissegundos: multiplique por 1000 e o instante é 1.789.689.600.000. Um instante, dois inteiros, a unidade movida por uma posição decimal em vez do momento se movendo. Um exemplo mais redondo torna a unidade visível: 315.532.800 são exatamente dez anos depois da época, 1 de janeiro de 1980 às 00:00:00 UTC, a contagem cruzando os anos bissextos 1972 e 1976 pelo caminho.
De timestamp para data: as seis linhas de volta
As seis linhas são seis relógios lendo um instante, não seis instantes diferentes. A linha ISO escreve 2026-09-18T00:00:00.000Z, com o Z que marca a zona UTC dentro da própria string. A linha UTC lê Fri, 18 Sep 2026 00:00:00 GMT. A linha local segue o fuso do navegador: o mesmo inteiro lê 09:00 em 18 de setembro em um navegador em Tóquio e 20:00 em 17 de setembro em um navegador em Nova York. As linhas legível, de data e de hora se renderizam no idioma do site; em português a linha legível dá sexta-feira, 18 de setembro de 2026, 00:00:00. Cada linha é um formato para o mesmo momento, escolhido para um destino: ISO para APIs e logs, UTC para comparações entre fusos, local para o leitor, legível para a exibição, e data ou hora quando falta só uma parte. Cada linha tem seu botão de copiar, de modo que o formato viaja sozinho.
De data para timestamp: a leitura em hora local
O modo inverso toma o relógio de parede, não o inteiro: um campo de data e um campo de hora, lidos como hora local no fuso em que o navegador está. O relógio de parede de 18 de setembro de 2026 às 12:00 lê 1.789.732.800 em um navegador em UTC, 1.789.700.400 em um navegador em Tóquio e 1.789.747.200 em um navegador em Nova York em horário de verão. Três inteiros diferentes para um mesmo relógio de parede, separados exatamente pelos deslocamentos de fuso: as mesmas 12:00 da parede são 03:00 em UTC em Tóquio e 16:00 em UTC em Nova York. A saída lista as duas unidades de uma vez, segundos e milissegundos; os segundos são os milissegundos divididos por 1000 e truncados, então as duas linhas são o mesmo instante escrito duas vezes. Este modo é a costura onde a data vira o instante exato em que o dia começa, a pergunta que o artigo da data futura carrega: uma data futura com seu momento de partida fixado.
O número de dígitos decide segundos ou milissegundos
O conversor não pergunta pela unidade; ele lê o número de dígitos. Até 10 dígitos se leem como segundos, de 11 a 13 se leem como milissegundos. As duas janelas chegam ao mesmo horizonte, o ano 2286: 9.999.999.999 como segundos é 20 de novembro de 2286 às 17:46:39 UTC, e 9.999.999.999.999 como milissegundos é esse mesmo instante escrito com os três zeros a mais. A janela de milissegundos começa em 10.000.000.000, que como milissegundos é 26 de abril de 1970 às 17:46:40 UTC, então todo valor em milissegundos escrito desde aquele dia se lê na unidade certa, e os valores de 13 dígitos dos últimos anos caem sem ambiguidade dentro da janela de milissegundos. A única brecha estreita está no começo de 1970: 1.000.000.000 tem 10 dígitos, então se lê como segundos, que é 9 de setembro de 2001 às 01:46:40 UTC, não os dezesseis minutos e quarenta segundos depois da época que os mesmos dígitos marcariam se fossem milissegundos. A regra troca um mal-entendido deliberado no primeiro trimestre de 1970 por um campo de entrada sem unidade que lê os valores modernos sem aviso.
O mesmo instante em dois relógios
O timestamp não carrega fuso; a leitura carrega. O instante âncora 1.789.689.600 está às 00:00 de 18 de setembro em UTC, às 02:00 de Berlim em horário de verão, às 09:00 de Tóquio e às 20:00 de 17 de setembro em Nova York. O inteiro é um único número em todos esses fusos; o relógio de parede é onde o fuso entra. Essa separação é o que torna as distâncias seguras: 1.789.732.800 menos 1.789.689.600 são 43.200 segundos, 12 horas, a mesma diferença em todos os fusos, porque os dois inteiros vivem no mesmo eixo UTC. A Calculadora de Datas em modo diferença reporta o mesmo trecho entre duas datas em dias, e o artigo da diferença de datas percorre esse modo do começo ao fim; a versão com inteiros da mesma subtração é aritmética inteira pura, sem calendário no meio.
Para onde viaja o inteiro
Fora do conversor, o inteiro é a moeda da máquina: as APIs o devolvem, os logs do servidor o marcam, os sistemas de arquivo o guardam, os bancos de dados ordenam por ele, e o relógio de parede é renderizado a partir dele no momento da leitura, no fuso em que o leitor estiver. A costura com a data é onde o fuso entra e os erros acontecem. Uma data de nascimento de 15 de janeiro de 1990 à meia-noite local é 632.361.600 lida em UTC e 632.329.200 lida em Tóquio, uma brecha de nove horas no inteiro para um mesmo relógio de parede. A Calculadora de Idade lê a data, não o inteiro, e preserva a meia-noite local como o instante do nascimento; o artigo da idade explica por que a leitura da meia-noite local é a fronteira entre uma idade certa e um dia de diferença. Na ponta distante da cadeia de planejamento, as datas que começam como inteiros saem do navegador: um empréstimo de 30 anos contratado aos 36 anos em 15 de janeiro de 2026 se quita aos 66 em 15 de janeiro de 2056, a Calculadora de Empréstimo carrega esse plano de pagamentos, e o Planejador de Aposentadoria carrega a data da aposentadoria da mesma forma, e cada um escreve suas datas finais de volta ao relógio de parede ao terminar.