Unix Time atinge 1,7 bilhão

Artigo original ↗ Discussão no Hacker News ↗

O Unix time recentemente ultrapassou 1,7 bilhão de segundos desde sua época em 1º de janeiro de 1970, levando programadores a marcar o momento com scripts, livestreams e numerologia bem-humorada. Além da novidade de um número arredondado, os participantes usam o marco para explorar tópicos mais profundos como segundos intercalares, diferenças entre UTC, TAI e outros padrões de tempo, e o iminente problema do Ano 2038 para timestamps de 32 bits. Muitos observam como esses marcos recorrentes da época funcionam como uma espécie de metrônomo de longo prazo para quem trabalha de perto com timestamps.

Marco e reações

  • O Unix time atingiu 1.700.000.000 segundos desde 1970-01-01, provocando posts de “celebração” bem-humorados e referências a marcos anteriores (1.2B, 1.4B, 1.5B, 1.6B, 1.666…B, 1.6G, 1.5G, 1400000000, 1234567890, 1,000,000,000).
  • Alguns comentaristas acham essa “numerologia” divertida e tratam esses momentos raros como instantes de metrônomo de longo prazo, até ligando-os a aniversários ou memórias pessoais.
  • Outros são indiferentes, questionando por que um número arredondado em base 10 importa, especialmente quando limiares semelhantes ocorrem a cada ~3 anos.

Assistindo à virada

  • Pessoas usaram loops de shell (date +%s, watch), Node.js, Deno REPL e snippets ad hoc em JS (com setInterval, geradores assíncronos, temporizadores com correção de desvio) para ver o contador avançar.
  • Alguns gravaram ou fizeram livestream do evento; outros brincaram sobre “tocar calculadoras” ou filmar para reproduzir depois.

Segundos intercalares, UTC e o que o Unix time realmente é

  • Houve um debate detalhado sobre se Unix time é “segundos desde a época” ou “dias×86400+segundos”, com ênfase em que o POSIX o define como uma aproximação que ignora segundos intercalares.
  • Esclarecimento de que:
    • Segundos intercalares significam que alguns dias reais têm 86401 segundos, mas o Unix time assume 86400.
    • Isso faz o Unix time divergir dos segundos SI reais decorridos e do TAI.
    • O Unix time não tem valores distintos para segundos intercalares; alguns timestamps mapeiam para intervalos reais de 2 segundos.
  • Discussão de diferentes padrões de tempo e casos de uso: UTC para atividade humana, TAI/Unix/GPS para tempo monotônico, UT1/solar aparente/sideral/TCB para astronomia e navegação.
  • Foi observado que a política de segundos intercalares do UTC está sendo reavaliada; futuros “minutos intercalares” são mencionados.

Marcos futuros e o problema de 2038

  • As pessoas apontam marcos futuros: 1.8B em 2027, 2.0B em 2033, 2,147,483,647 (máximo de 32 bits com sinal) e 2,147,483,648.
  • O problema de 2038 é discutido como um “próximo Y2K”: sistemas modernos em sua maioria usam timestamps de 64 bits, mas dispositivos legados de 32 bits e embarcados (incluindo código gravado em ROM) continuam sendo uma preocupação.
  • Alguns lembram o Y2K tanto como um esforço genuíno de engenharia quanto como um apocalipse exagerado; notam que o medo às vezes ajuda a fazer sistemas serem corrigidos.

Épocas, calendários e detalhes de representação

  • Debate sobre usar 1970 versus “ano 1” como época; outros observam que muitas eras de calendário existem e que a numeração dos anos do calendário gregoriano é, por si só, arbitrária.
  • Menciona-se que a representação de tempo do Go usa o ano 1 e que máquinas muito antigas tornavam uma época no ano 1 impraticável.
  • Um comentarista argumenta fortemente a favor de TAI em vez de Unix time por correção.
  • Orientação do Protobuf: evitar inteiros de comprimento variável para timestamps; tamanho fixo (fixed32/fixed64) costuma ser menor e mais rápido.