Se és programador e já precisaste de saber quando foi criado um servidor, mensagem ou conta a partir apenas do seu ID numérico — ou de montar uma cláusula SQL BETWEEN correta para um relatório mensal — este guia cobre dois casos avançados que o timestamp Unix "simples" não resolve sozinho.
Quando um sistema precisa de gerar milhões de IDs únicos por segundo em vários servidores distribuídos, um contador sequencial simples não chega — dois servidores diferentes podiam gerar o mesmo número ao mesmo tempo. A solução «snowflake», popularizada pelo Twitter e adotada pelo Discord, combina num único inteiro de 64 bits: um timestamp (deslocado para a esquerda), um identificador de worker/servidor, e um contador de sequência. O resultado é um ID que é simultaneamente único e ordenável cronologicamente — quanto maior o número, mais recente o registo.
O processo, em termos simples, é sempre o mesmo: interpretar o ID como um número inteiro grande, deslocar os seus bits 22 posições para a direita (o que remove os bits reservados para worker ID e sequência), e somar o valor resultante ao epoch de arranque próprio dessa plataforma. A tabela seguinte mostra os dois epochs de referência mais usados:
| Plataforma | Epoch de referência (ms) | Corresponde a |
|---|---|---|
| Discord | 1420070400000 | 1 de janeiro de 2015, 00:00 UTC |
| Twitter/X | 1288834974657 | 4 de novembro de 2010 (lançamento do snowflake) |
Como estes números ultrapassam os limites seguros de precisão de um número normal em JavaScript, a operação deve ser feita com aritmética BigInt (ou equivalente noutra linguagem), não com operações numéricas comuns — caso contrário, os bits menos significativos perdem-se e o timestamp resultante fica ligeiramente incorreto. Um descodificador de ID snowflake dedicado trata este cálculo automaticamente: colas o ID, escolhes a plataforma, e recebes a data-hora exata de criação.
BETWEEN.Um cenário comum em análise de dados: precisas de filtrar todos os registos de uma base de dados que caem dentro de um mês específico, mas a coluna de data está armazenada como epoch (inteiro), não como data legível. Calcular manualmente "epoch do dia 1 às 00:00:00" e "epoch do último dia às 23:59:59" à mão é lento e propenso a erros de fuso horário — especialmente perto da mudança de hora de verão.
Uma mini-ferramenta de intervalo de datas em epoch resolve isto diretamente: escolhes uma data qualquer dentro do período pretendido, selecionas o âmbito (dia / mês / ano) e se queres o cálculo em hora local ou UTC, e recebes imediatamente os dois valores limite, em segundos e em milissegundos, prontos para colar numa cláusula SQL como:
WHERE created_at BETWEEN 1748736000 AND 1751327999 — os dois números representam o início e o fim de um mês fictício em segundos epoch UTC.Este é um erro subtil e frequente: ao construir manualmente um intervalo mensal, é tentador usar "o primeiro dia do mês seguinte às 00:00:00" como limite superior e assumir que está tudo incluído — mas dependendo de como a comparação SQL é feita (< vs. <=), isto pode excluir a última fração de segundo do mês, ou pior, incluir acidentalmente registos do dia seguinte. Gerar explicitamente o epoch de fim de período com a hora 23:59:59 (ou o início do dia seguinte com um operador estritamente menor que) elimina esta ambiguidade.
Este tipo de descuido é particularmente comum em relatórios financeiros ou de auditoria mensais, onde um único registo em falta ou duplicado pode distorcer totais — por isso vale a pena gerar os limites do intervalo com uma ferramenta dedicada em vez de calculá-los de cabeça.
Descodifica IDs snowflake e gera intervalos epoch prontos para SQL — grátis e direto no navegador.
Experimentar o Conversor de timestamp Unix →