Conversor de tempo Unix Epoch e gerador de carimbo de data / hora Discord

Converta carimbos de data/hora da época Unix em datas legíveis por humanos e vice-versa. Gere carimbos de data/hora do Discord que podem ser copiados e colados em tempo real.

Tempo Unix em Tempo Real
segundos 0000000000
milissegundos 0000000000000
Hora Local
-
Hora UTC
-
Unix Epoch (sec)
-
Unix Epoch (ms)
-
Tempo Relativo
-
Comparador de Fusos Horários Slide this handle to synchronize and visually compare the local and UTC dates and times across all selected timezones in real time.

Deslize a linha do tempo para comparar visualmente múltiplos fusos horários.

-12h -6h UTC (0) +6h +12h

                                
                            

Sincronizar sistemas de banco de dados distribuídos, registrar eventos de aplicativos e depurar cargas de API exigem um método padronizado e altamente preciso de controle de tempo. A padronização no tempo de época do Unix fornece um número inteiro imutável e independente do fuso horário que representa o número exato de segundos decorridos desde 1º de janeiro de 1970. Este guia abrangente detalha a mecânica dos carimbos de data e hora do Unix, demonstra métodos de conversão programática em ambientes modernos e explica como analisar estruturas de tempo alternativas, como IDs de floco de neve do Discord.

Compreendendo o tempo da época Unix e a dinâmica do carimbo de data / hora

A hora Unix (também conhecida como época Unix, hora POSIX ou carimbo de data/hora Unix) rastreia o progresso cronológico como um número inteiro incremental. Representa a contagem de segundos decorridos desde o ponto de referência de 1º de janeiro de 1970, 00:00:00 UTC (representação ISO 8601: 1970-01-01T00:00:00Z). No exato momento desta época, o contador estava exatamente em 0.

Os carimbos de data e hora da época são estritamente independentes do fuso horário. O número inteiro representa um instante universal singular em todo o mundo, e os aplicativos clientes locais ajustam a camada de apresentação aplicando compensações UTC específicas. Para ver como funciona o mapeamento de fuso horário, compare as interpretações locais do carimbo de data/hora 1577923200:

Região do fuso horário Data e hora localizadas Valor de deslocamento
GMT/UTC Quinta-feira, 2 de janeiro de 2020, 00:00:00 UTC+00:00
Índia (Calcutá) Quinta-feira, 2 de janeiro de 2020, 05:30:00 UTC+05:30
América (Nova York) Quarta-feira, 1º de janeiro de 2020, 19:00:00 UTC-05:00

O tempo Unix não leva em conta segundos bissextos. Em vez disso, ele assume que cada dia do calendário contém exatamente 86.400 segundos. Como os segundos bissextos são ignorados no contador (compartilhando exatamente o mesmo valor de carimbo de data/hora do segundo anterior), o tempo da época Unix não mantém uma sincronização linear perfeita com o Tempo Universal Coordenado (UTC) em longos períodos geológicos. Para datas anteriores ao limite inicial de 1º de janeiro de 1970, o sistema utiliza valores inteiros negativos (por exemplo, -86400 denota 31 de dezembro de 1969, 00:00:00 UTC).

Para trabalhar com esses números na modelagem de banco de dados ou em tarefas de trabalho em segundo plano, os desenvolvedores contam com intervalos cronológicos fixos. A lista a seguir mapeia unidades padrão para seus valores exatos em segundos:

  • 1 hora: 3.600 segundos
  • 1 dia: 86.400 segundos
  • 1 semana: 604.800 segundos
  • 1 mês (calculado em 30,44 dias): 2.629.743 segundos
  • 1 ano (calculado em 365,24 dias): 31.556.926 segundos

O cálculo dos valores de duração diretamente com esses valores facilita o gerenciamento de cronogramas cron, a expiração de tokens JWT ou a criação de índices TTL personalizados em bancos de dados NoSQL.

Segundos x milissegundos: navegação com precisão de dígitos

Os carimbos de data e hora em softwares modernos são executados em vários níveis de precisão, dependendo dos requisitos da aplicação. A maioria dos projetos de sistema utiliza uma destas quatro resoluções:

  1. Segundos (formato de 10 dígitos): Por exemplo, 1735689600. Esta é a resolução padrão usada por Python, PHP, bancos de dados relacionais (como PostgreSQL e MySQL) e ambientes shell Linux.
  2. Milissegundos (formato de 13 dígitos): Por exemplo, 1735689600000. Esse formato é padrão em JavaScript, Java e na maioria das APIs da web modernas baseadas em JSON.
  3. Microssegundos (formato de 16 dígitos): Por exemplo, 1735689600000000. Normalmente reservado para rastreamento de alta precisão, registro do sistema e plataformas de diagnóstico de baixo nível.
  4. Nanossegundos (formato de 19 dígitos): Utilizados em sistemas especializados de rastreamento em nível de kernel e redes de processamento em tempo real.

Para converter segundos em milissegundos, multiplique o valor inteiro por 1.000. Por outro lado, para transformar milissegundos de volta em segundos padrão, aplique a divisão inteira por 1.000 para eliminar os dígitos finais.

Compreender os carimbos de data/hora Unix sequenciais e de referência fornece uma perspectiva clara sobre a progressão cronológica e a escala:

Carimbo de data/hora Unix Data e hora UTC equivalentes Contexto do marco
0 Quinta-feira, 1º de janeiro de 1970, 00:00:00 UTC A época Unix
1.000.000.000 Domingo, 9 de setembro de 2001, 01:46:40 UTC O milionésimo segundo marco
1.234.567.890 Sexta-feira, 13 de fevereiro de 2009, 23:31:30 UTC Progressão sequencial de dígitos decimais
1.735.689.600 Quarta-feira, 1º de janeiro de 2025, 00:00:00 UTC Início do ano 2025
2.000.000.000 Terça-feira, 18 de maio de 2033, 03:33:20 UTC Segundo marco de dois bilhões
2.147.483.647 Terça-feira, 19 de janeiro de 2038, 03:14:07 UTC O limite máximo absoluto de 32 bits assinados

O problema do ano 2038: por que os sistemas de 32 bits falham

Sistemas legados, firmware incorporado e esquemas de banco de dados que armazenam carimbos de data/hora Unix como números inteiros de 32 bits assinados eventualmente encontrarão um limite de estouro. Um número inteiro assinado de 32 bits só pode armazenar valores até 2.147.483.647. O ponto de ruptura exato ocorre em 19 de janeiro de 2038, às 03:14:07 UTC.

No próximo tique do relógio do sistema (03:14:08 UTC), o contador inteiro transborda e atinge seu limite mínimo negativo de -2,147,483,648. Os sistemas que não conseguirem lidar com esta transição interpretarão a data como 13 de dezembro de 1901. Isso provocará falhas no sistema, invalidações de certificados, erros no sistema de arquivos e consultas de banco de dados corrompidas.

Métodos programáticos para converter e gerar carimbos de data/hora Unix

Para ajudar os desenvolvedores a capturar a hora atual e realizar conversões, a tabela abaixo descreve métodos para recuperar carimbos de data e hora de época padrão e converter um valor genérico (usando 1800000000 como referência) de volta para horários locais em diferentes idiomas e plataformas.

Idioma/Plataforma Época Atual (Segundos) Converter época em data
JavaScript Math.floor(Data.agora()/1000) nova data(1800000000 * 1000).toLocaleString()
Pitão int(hora.hora()) hora.ctime(1800000000)
Java Instant.now().getEpochSecond() new SimpleDateFormat("MM/dd/yyyy HH:mm:ss").format(nova data(1800000000L * 1000))
Ir hora.Agora().Unix() tempo.Unix(1800000000, 0)
PHP tempo() data('r', 1800000000)
Rubi Hora.agora.para_i Hora.at(1800000000)
C# DateTimeOffset.Now.ToUnixTimeSeconds() DateTimeOffset.FromUnixTimeSeconds(1800000000).LocalDateTime
C++ duração_cast(system_clock::now().time_since_epoch()).count() -
Ferrugem SystemTime::now().duration_since(UNIX_EPOCH).unwrap().as_secs() -
Perl tempo hora local escalar (1800000000)
PostgreSQL SELECT EXTRACT(ÉPOCA DE agora()); SELECIONE TO_TIMESTAMP(1800000000);
MySQL SELECIONE UNIX_TIMESTAMP(AGORA()); SELECIONE FROM_UNIXTIME(1800000000);
Servidor SQL SELECIONE DATEDIFF(SEGUNDO, '1970-01-01', GETUTCDATE()); SELECIONE DATEADD(SEGUNDO, 1800000000, '1970-01-01');
SQLite SELECT unixepoch(); SELECIONE data e hora(1800000000, 'unixepoch');
Shell Unix/Linux data +%s data -ud@1800000000
macOS data +%s data -j -r 1800000000
PowerShell [DateTimeOffset]::Now.ToUnixTimeSeconds() [DateTimeOffset]::FromUnixTimeSeconds(1800000000).LocalDateTime
Excel / Planilhas - =(A1/86400) + 25569

Épocas personalizadas e geradores de carimbo de data/hora de floco de neve Discord

Diferentes arquiteturas usam épocas de referência especializadas e resoluções de incremento dependendo das plataformas de hardware, bancos de dados ou especificações de aplicativos. Alguns desses formatos incluem:

  • Carimbo de data e hora LDAP: conta em blocos de 100 nanossegundos a partir de 1º de janeiro de 1601.
  • .NET DateTime Ticks: Contagens em blocos de 100 nanossegundos a partir do Ano Gregoriano 1.
  • Carimbo de data e hora do Chrome/WebKit: conta em microssegundos a partir de 1º de janeiro de 1601.
  • Mac HFS+: Contagem em segundos a partir de 1º de janeiro de 1904.
  • Registro de data e hora NTP: Contagem em segundos a partir de 1º de janeiro de 1900.
  • Tempo GPS: Contagem em segundos e semanas a partir de 6 de janeiro de 1980.
  • Carimbo de data e hora do SAS: Contagem em segundos ou dias a partir de 1º de janeiro de 1960.
  • Dados principais do cacau: Contagem em segundos a partir de 1º de janeiro de 2001.
  • Excel OADate: Conta em dias fracionários a partir de 1º de janeiro de 1900.
  • Carimbo de data/hora FAT: Conta em segundos a partir de 1980 ou 2000.
  • Dia Juliano: Mede o progresso cronológico em dias a partir de antigos pontos de referência astronômicos.
  • Snowflake ID: Um formato de indexação de carimbo de data/hora descentralizado usado pelo Discord e Twitter (X).

Noções básicas sobre carimbos de data/hora do Discord e IDs de floco de neve

O Discord gera inteiros não assinados de 64 bits (IDs de floco de neve) exclusivos e descentralizados para identificar objetos como mensagens, canais, servidores e usuários. Ao contrário dos números inteiros incrementais padrão ou UUIDs de alta sobrecarga, um floco de neve Discord incorpora o tempo exato de criação dentro do próprio ID, o que ajuda no desempenho em sistemas distribuídos.

A estrutura de um ID de floco de neve Discord é dividida em quatro componentes distintos:

  • Carimbo de data/hora (42 bits): Representa os milissegundos decorridos desde a época personalizada do Discord (definida como 1º de janeiro de 2015, às 00:00:00 UTC, equivalente ao carimbo de data/hora Unix 1420070400000).
  • ID do trabalhador (5 bits): Representa o índice interno do trabalhador do servidor.
  • ID do processo (5 bits): Representa o índice do processo interno.
  • Incremento (12 bits): Um contador sequencial que é redefinido para 0 a cada milissegundo por processo.

Para exibir datas legíveis em mensagens do Discord que se ajustam automaticamente ao fuso horário local do usuário que está visualizando, os desenvolvedores usam geradores de carimbo de data/hora do Discord. Inserir um carimbo de data/hora Unix padrão nesses geradores produz uma string de redução formatada. A tabela abaixo lista os formatos de estilo disponíveis:

Sintaxe de redução Exemplo de saída (para Unix 1735689600) Descrição do estilo de exibição
<t:1735689600:t> 00:00 Pouco tempo
<t:1735689600:T> 00:00:00 Muito tempo
<t:1735689600:d> 01/01/2025 Data curta
<t:1735689600:D> 1º de janeiro de 2025 Data Longa
<t:1735689600:f> 1º de janeiro de 2025 00:00 Data/hora abreviada
<t:1735689600:F> Quarta-feira, 1º de janeiro de 2025 00:00 Data/hora longa
<t:1735689600:R> em 5 anos / 5 anos atrás Tempo relativo

Otimizando fluxos de trabalho de tempo em sistemas distribuídos

O gerenciamento de cálculos de tempo em sistemas distribuídos modernos requer uma abordagem padronizada para evitar desvios de fuso horário, erros de dimensionamento de carga útil e falhas de overflow. A padronização de estruturas de banco de dados na época Unix padrão simplifica as tarefas de manipulação de tempo, garantindo operações consistentes em microsserviços e interfaces externas.

Ao projetar APIs ou configurar filas de mensagens, lembre-se destas três diretrizes:

  1. Armazene a hora em formato UTC ou inteiro de época: Mantenha as camadas de persistência livres de compensações de fuso horário local. Aplique localizações exclusivamente na camada de apresentação.
  2. Priorize a representação de 64 bits: Ao projetar colunas de banco de dados ou selecionar estruturas de programação, migre dos tipos de 32 bits para evitar estouros de tempo de execução do ano 2038.
  3. Escolha a precisão apropriada: Corresponda às especificações do sistema (por exemplo, usando milissegundos para eventos de API e nanossegundos somente ao rastrear aquisições de bloqueios distribuídos).

Ao converter carimbos de data/hora ou verificar épocas usando utilitários de navegador, a segurança e a privacidade são fundamentais. A ferramenta de conversão do Toolsaur implementa esta filosofia diretamente: "Todo o processamento é executado localmente no seu navegador. Seus dados nunca são enviados para nossos servidores." Isso garante que os logs confidenciais do sistema contendo carimbos de data/hora do banco de dados nunca vazem para endpoints de terceiros.

Perguntas frequentes sobre conversores de época

Por que os carimbos de data/hora Unix são independentes do fuso horário?

Os carimbos de data/hora Unix representam o tempo absoluto decorrido desde um único ponto de referência global (1º de janeiro de 1970, às 00:00:00 UTC). Como esse ponto inicial de referência é idêntico, independentemente da localização geográfica, o número inteiro do carimbo de data/hora calculado permanece o mesmo. O ajuste de fuso horário local só é aplicado ao formatar o carimbo de data/hora em uma sequência de data legível por humanos nas interfaces do cliente.

Qual é a diferença entre um carimbo de data/hora de 10 e 13 dígitos?

Um carimbo de data/hora de 10 dígitos representa a precisão em segundos (por exemplo, 1735689600), o que é típico para sistemas operacionais POSIX, Python e bancos de dados SQL. Um carimbo de data/hora de 13 dígitos representa a precisão em milissegundos (por exemplo, 1735689600000), que é padrão para tempos de execução JavaScript, Java e APIs REST modernas. Mover-se entre eles requer multiplicar ou dividir por 1.000.

Como o problema do ano 2038 afetará os bancos de dados modernos?

Se uma coluna de banco de dados armazenar carimbos de data/hora Unix usando um tipo de dados inteiro assinado de 32 bits (como INT em esquemas de banco de dados mais antigos), qualquer registro com carimbo de data/hora além de 19 de janeiro de 2038, 03:14:07 UTC causará um estouro. Isso envolve o número em um valor negativo, interpretando datas futuras como 13 de dezembro de 1901. Os sistemas devem migrar essas colunas para números inteiros assinados de 64 bits (BIGINT).

Como o tempo Unix lida com segundos bissextos?

O tempo Unix não leva em conta segundos bissextos e assume que cada dia tem exatamente 86.400 segundos. Quando ocorre um segundo bissexto, o carimbo de data/hora Unix é repetido ou interrompido por um segundo. Esta escolha de design simplifica o cálculo matemático, mas causa pequenos desvios nos cronogramas exatos do Tempo Universal Coordenado (UTC).

O que é um ID de floco de neve do Discord e como ele difere de um carimbo de data/hora Unix padrão?

Um ID de floco de neve do Discord é um número inteiro não assinado personalizado de 64 bits que codifica um carimbo de data/hora de criação junto com os metadados da arquitetura do servidor (ID do trabalhador, ID do processo e um incremento local). Ao contrário de um carimbo de data/hora Unix padrão de 10 dígitos em segundos, um ID de floco de neve usa uma época personalizada começando em 1º de janeiro de 2015 e rastreia intervalos em milissegundos, armazenando esse tempo de alta precisão nos primeiros 42 bits do ID.

Como você pode converter um carimbo de data/hora de época no Microsoft Excel?

O Excel rastreia as datas como o número de dias decorridos desde 1º de janeiro de 1900. Para converter um carimbo de data / hora Unix padrão de 10 dígitos (segundos) na célula A1 em uma data legível no Excel, aplique a fórmula =(A1 / 86400) + 25569, onde 86400 é o número de segundos em um dia e 25569 é o deslocamento em dias entre a época do Excel e a época do Unix. Defina a formatação da célula como “Data” ou “Hora” para visualizar a saída.