FAQ do Conversor de timestamp Linux
Q: What is a Unix timestamp?
A: Um timestamp Unix (também conhecido como tempo POSIX ou tempo epoch) é o número de segundos decorridos desde 1 de janeiro de 1970, 00:00:00 UTC, excluindo segundos bissextos. É um inteiro simples que representa o mesmo momento em todo o mundo, independentemente do fuso horário.
Q: How do I convert a Unix timestamp to a human-readable date?
A: Você pode converter um timestamp Unix de várias maneiras:
- Online: Use nosso Conversor de Timestamp Unix para conversão instantânea
- Terminal Linux: Execute
date -d @1785292800(no GNU/Linux) oudate -r 1785292800(no macOS) - JavaScript:
new Date(timestamp * 1000).toISOString() - Python:
datetime.utcfromtimestamp(1785292800) - PHP:
date("Y-m-d H:i:s", 1785292800)
Q: What is the difference between seconds and milliseconds timestamps?
A: Um timestamp baseado em segundos tem 10 dígitos (ex.: 1785292800). Um timestamp em milissegundos tem 13 dígitos (ex.: 1785292800000) porque multiplica o valor em segundos por 1000. O Date.now() do JavaScript retorna milissegundos, enquanto a maioria dos outros sistemas e APIs usa segundos. Misturá-los acidentalmente produz datas extremamente erradas — usar milissegundos onde se esperam segundos gera uma data aproximadamente 56.000 anos no futuro.
Sempre verifique a resolução da sua fonte de dados antes de converter. Em caso de dúvida, conte os dígitos: 10 dígitos = segundos, 13 dígitos = milissegundos.
Q: Can Unix timestamps represent dates before 1970?
A: Sim. Datas anteriores a 1 de janeiro de 1970 são representadas como números negativos. Por exemplo, o timestamp -3600 corresponde a 31 de dezembro de 1969, 23:00:00 UTC. Nem todas as ferramentas de conversão lidam corretamente com timestamps negativos, mas nosso conversor online lida. As linguagens de programação os suportam universalmente.
Q: What is the Year 2038 problem?
A: O problema do ano 2038 (também chamado de Y2K38) é uma questão de representação de tempo que afeta sistemas que armazenam timestamps como inteiros com sinal de 32 bits. O valor máximo é 2147483647, que corresponde a 19 de janeiro de 2038, às 03:14:07 UTC. Um segundo depois, o valor transborda para -2147483648, interpretado como 13 de dezembro de 1901.
A maioria dos sistemas modernos de 64 bits não é afetada, mas dispositivos embarcados, bancos de dados legados e alguns sistemas de 32 bits permanecem vulneráveis. A solução é migrar para representações de tempo de 64 bits, que fornecem um alcance de aproximadamente 292 bilhões de anos.
Q: Do Unix timestamps account for leap seconds?
A: Não. Os timestamps Unix ignoram intencionalmente os segundos bissextos. Cada dia é tratado como exatamente 86.400 segundos, mesmo quando um segundo bissexto é adicionado ao UTC. Durante uma inserção de segundo bissexto, o timestamp Unix não avança por um segundo, efetivamente pulando o segundo bissexto. Isso significa que os timestamps Unix divergem do tempo atômico por uma pequena (atualmente cerca de 27 segundos) mas crescente quantidade.
Q: How do I handle timezones when converting Unix timestamps?
A: Um timestamp Unix representa o mesmo momento em qualquer lugar. O fuso horário só importa quando você o exibe como uma data legível por humanos. Sempre armazene timestamps em sua forma inteira bruta e converta para a hora local apenas para exibição. Use nomes de fusos horários IANA como America/New_York em vez de abreviações como EST ou PST, pois as abreviações não levam em conta o horário de verão. Nosso Conversor de Timestamp Unix exibe resultados em vários fusos horários simultaneamente.
Q: What is the maximum Unix timestamp?
A: O máximo depende do tamanho do inteiro usado para armazenamento:
- Inteiro com sinal de 32 bits:
2147483647(19 de janeiro de 2038, 03:14:07 UTC) - Inteiro sem sinal de 32 bits:
4294967295(7 de fevereiro de 2106, 06:28:15 UTC) - Inteiro com sinal de 64 bits:
9223372036854775807(aproximadamente 292 bilhões de anos a partir de agora)
A maioria dos sistemas modernos usa inteiros de 64 bits, fornecendo um alcance efetivamente infinito. A prática comum de armazenar timestamps em colunas de banco de dados ou estruturas de dados como um tipo de 64 bits (BIGINT em SQL) é à prova do futuro.