Unix Timestamp: o que é, conversão e armazenamento no desenvolvimento móvel

O que é Unix Timestamp?

Unix Timestamp (também conhecido como POSIX time, Epoch time ou Unix time) é um sistema de medição de tempo que define o número de segundos decorridos desde 1 de janeiro de 1970 00:00:00 UTC (a época Unix). Esta data foi escolhida como ponto de partida para o sistema operacional Unix, e posteriormente o formato tornou-se o padrão de facto para representar o tempo em sistemas computacionais. O timestamp não considera segundos bissextos — cada minuto é contado como 60 segundos, embora o Serviço Internacional de Rotação da Terra ocasionalmente adicione um segundo extra para corrigir o tempo atômico.

A época Unix: porquê 1970?

A escolha de 1 de janeiro de 1970 está ligada à história do sistema operacional Unix. Os desenvolvedores Ken Thompson e Dennis Ritchie selecionaram esta data como um ponto de partida redondo e simples — era suficientemente cedo para acomodar todas as datas possíveis e suficientemente tarde para que o tempo pudesse ser armazenado num inteiro com sinal de 32 bits. Inicialmente, o tempo era medido em sessenta avos de segundo, depois em ticks (1/60 de segundo), e apenas na Sétima Edição do Unix (V7, 1979) o formato se estabilizou como um número inteiro de segundos. De acordo com The Open Group Base Specifications (Issue 8, 2024), os sistemas compatíveis com POSIX são obrigados a suportar este formato.

Como funciona o Unix Timestamp

O princípio de funcionamento do Unix Timestamp baseia-se num contador simples: cada dia que passa adiciona 86 400 segundos ao valor. Por exemplo, o timestamp 1 720 000 000 corresponde a uma data em meados de 2024 — a conversão exata pode ser feita dividindo pelo número de segundos num dia, hora e minuto. Esta abordagem torna o timestamp ideal para armazenamento em máquina: é um número inteiro que ocupa 4 bytes (int de 32 bits) ou 8 bytes (long de 64 bits) e suporta comparação direta — um timestamp maior = uma data mais tardia.

Matemática de conversão

Um dia = 86 400 segundos (24 x 60 x 60). Uma hora = 3600 segundos. Para converter um timestamp numa data, é necessário calcular sequencialmente o número de dias, horas, minutos e segundos desde a época. A conversão inversa — converter uma data em dias desde 1970-01-01, depois multiplicar por 86 400 e adicionar o desvio UTC. Em Java e Kotlin, estes cálculos já estão implementados nas classes padrão java.time.Instant e java.util.Date, o que poupa o desenvolvedor de cálculos manuais.

        // Obter Unix Timestamp em segundos
val seconds = System.currentTimeMillis() / 1000

// Converter timestamp para data via java.time
val instant = Instant.ofEpochSecond(seconds)
val localDate = instant.atZone(ZoneId.of("Europe/Moscow")).toLocalDate()

// Inverso: data para timestamp
val date = LocalDate.of(2026, 7, 21)
val ts = date.atStartOfDay(ZoneOffset.UTC).toEpochSecond()

Conversão de Unix Timestamp para data e vice-versa

A conversão de Unix Timestamp para uma data legível por humanos é uma das operações mais comuns no desenvolvimento móvel. No Android, vários métodos de conversão estão disponíveis dependendo da versão mínima da API: para API 26+ recomenda-se usar java.time.Instant, para versões mais antigas usam-se java.util.Date e java.text.SimpleDateFormat. É importante lembrar que o Android e a JVM usam milissegundos por padrão, não segundos — se o timestamp for recebido do servidor em segundos, deve ser multiplicado por 1000 antes de ser passado aos construtores padrão.

Conversão com fuso horário

Uma das principais vantagens do Unix Timestamp é a independência de localização. O servidor devolve sempre o timestamp em UTC, e a conversão para data e hora local é realizada no lado do cliente. Em Kotlin, utiliza-se ZonedDateTime com o ZoneId apropriado — o do sistema ou o selecionado pelo utilizador. Se uma aplicação mostra horas em diferentes fusos horários (por exemplo, para viajantes), o timestamp elimina a necessidade de passar o fuso horário do servidor — um único marcador de tempo é suficiente.

// Converter com fuso horário do utilizador
fun formatTimestamp(seconds: Long, zoneId: ZoneId): String {
    val instant = Instant.ofEpochSecond(seconds)
    val formatter = DateTimeFormatter
        .ofPattern("dd.MM.yyyy HH:mm:ss")
    return formatter.format(instant.atZone(zoneId))
}

// Exemplo: timestamp = 1720000000, zone = Europe/Moscow
val result = formatTimestamp(1720000000, ZoneId.of("Europe/Moscow"))

O problema do ano 2038

O problema do ano 2038 (Y2K38) é uma limitação fundamental de armazenar Unix Timestamp como um inteiro com sinal de 32 bits. O valor máximo de um int com sinal de 32 bits é 2 147 483 647, que corresponde a 19 de janeiro de 2038 às 03:14:07 UTC. Após esta data, o valor transborda e torna-se um número negativo, causando falhas em sistemas que usam time_t de 32 bits. O problema é semelhante ao conhecido Y2K, mas afeta principalmente sistemas embarcados, versões antigas do Android e dispositivos IoT com arquitetura de 32 bits.

Escala do problema

De acordo com a Linux Foundation (2025), cerca de 15% dos dispositivos Linux nos segmentos industrial e IoT ainda usam compilações de 32 bits. Para dispositivos Android, o risco é menor — a maioria dos smartphones modernos funciona com processadores de 64 bits (ARM64), mas modelos antigos com Android 4.x e inferiores podem usar time_t de 32 bits. A solução é a migração para time_t de 64 bits, que é seguro até 292 mil milhões de anos. A partir do Android 5.0 (API 21), todos os dispositivos usam tempo de 64 bits ao nível do kernel. Os desenvolvedores de aplicações móveis precisam apenas de armazenar o timestamp como Long (64 bits) para evitar o problema ao nível da aplicação.

Trabalhando com Unix Timestamp no Android

No desenvolvimento Android, o manuseamento correto do Unix Timestamp é crítico para a sincronização de dados, exibição de horas de receção de mensagens, cálculo de timeouts e agendamento de notificações. A chamada de sistema System.currentTimeMillis() devolve a hora atual em milissegundos desde a época Unix — esta é a fonte de tempo mais precisa disponível no dispositivo. Para pedidos de rede, geralmente utiliza-se o Unix Timestamp em segundos, já que a maioria das REST APIs e bancos de dados operam em segundos.

Práticas recomendadas

Nunca use System.currentTimeMillis() para medir intervalos — para este propósito existe System.nanoTime(), que é monotónica e não é afetada por alterações de relógio do utilizador. Para exibir horas, guarde sempre o timestamp em UTC e converta para o fuso horário local no lado da interface do utilizador. Ao trabalhar com bancos de dados (SQLite, Room), use o tipo INTEGER e armazene o timestamp em segundos — isto ocupa 8 bytes (Long) e suporta ordenação nativa de SQL. Para serialização JSON, recomenda-se enviar o timestamp como um número (Long) em vez de uma string — é mais compacto e analisa mais rapidamente.

// Medição correta do tempo de execução
val start = System.nanoTime()
// ... operação ...
val elapsed = System.nanoTime() - start
val seconds = elapsed / 1_000_000_000.0

// Armazenar em Room (Entity)
@Entity
data class Message(
    @PrimaryKey val id: Long,
    val text: String,
    val createdAt: Long // Unix Timestamp em segundos
)

Manuseamento do tempo do servidor

Ao receber um Unix Timestamp do servidor, verifique sempre a unidade de medida: algumas APIs devolvem milissegundos (compatíveis com JavaScript), outras devolvem segundos (padrão POSIX). O acordo sobre as unidades deve ser documentado na especificação da API. Na resposta do servidor, o timestamp pode ser passado como Long (número JSON) ou String (ISO 8601). Para depuração, adicione uma função utilitária que mostre o timestamp num formato legível por humanos — isto simplifica a verificação dos marcadores de tempo durante o desenvolvimento.

Armazenamento de marcadores de tempo em bancos de dados

A escolha do formato de armazenamento de tempo numa base de dados afeta diretamente o desempenho das consultas, a complexidade do código e a correção do manuseamento de fusos horários. Unix Timestamp é o formato mais eficiente para bancos de dados relacionais: é armazenado como um número inteiro (4 ou 8 bytes), suporta indexação e permite ordenação rápida. Ao contrário das strings ISO 8601, o timestamp não requer análise para ordenação e ocupa menos espaço num índice. Para Room e SQLite, recomenda-se armazenar o timestamp como INTEGER e usar um índice na coluna de tempo.

Recomendações para projetos móveis

Para aplicações Android com a biblioteca Room, recomenda-se armazenar os timestamps como Long (64 bits) e usar um TypeConverter para conversão automática entre Long e Date ou Instant. Ao consultar a base de dados, use operadores de comparação (>, <, BETWEEN) — funcionam nativamente com tipos inteiros. Para armazenar em cache dados que requerem ordenação por tempo (por exemplo, uma lista de mensagens), crie sempre um índice na coluna de timestamp — isto acelerará consultas com ORDER BY em várias ordens de grandeza com grandes volumes de dados.