Cite Alguns Formatos De Data E Hora

Formatos de data e hora que todo desenvolvedor precisa conhecer

Trabalhando com sistemas que cruzam fusos horários, já vi muita dor de cabeça causada por formatos mal interpretados. Vou listar os mais relevantes e explicar onde cada um aparece na prática, sem rodeio. A questão não é só saber as siglas. É entender onde elas se chocam. O ISO 8601 parece universal, mas na prática as pessoas esquecem o sufixo Z de UTC ou confundem semana do ano com dia do mês. Um caso que comigo aconteceu: migrei um legacy que exportava datas no formato americano MM/DD/YYYY para um sistema que esperava DD/MM/YYYY. O resultado foram dados corrompidos em janeiro e fevereiro de todo o ano, porque todo mês parecia dia. A correção foi impor parsing explícito com DateTime.ParseExact usando um array de formatos, e nunca confiar no Thread.CurrentCulture de terceiros. Aqui vão os formatos que realmente importam no dia a dia.

ISO 8601 — o padrão que deveria ser obrigatório

A versão básica é algo como 2025-07-14T16:30:00. O sufixo Z indica UTC, e offset como +03:00 indica fuso local. O padrão permite versões compactas como 20250714T163000Z, mas isso só funciona bem quando ninguém precisa ler o dado manualmente. Semana do ano usa formato como 2025-W29-1, que é semana 29, segunda-feira. Isso evita aquela discussão interminável sobre quantas semanas tem um ano, porque a norma define claramente que a semana 1 é a que contém o primeiro quinta-feira de janeiro. O problema prático: muitos frameworks aceitam ISO 8601 de formas ligeiramente diferentes. JSON.NET, System.Text.Json e bibliotecas JavaScript tratam segundos fracionários de maneiras distintas. A solução é padronizar com precisão de milissegundos e sempre incluir o offset. Evite datas sem horário; isso é pedido de desastre para relatórios.

Unix timestamp — a escolha certa para sistemas

É um número inteiro que representa segundos desde 01/01/1970 às 00:00:00 UTC. Exemplo: 1752512400. Vantagem óbvia: comparação direta, armazenamento compacto e zero ambiguidade de fuso porque o valor é intrinsicamente UTC. Frameworks como .NET usam DateTimeOffset.ToUnixTimeSeconds(), e em JavaScript você pega com Math.floor(Date.now() / 1000). O ponto cego: timestamps de milissegundos versus segundos. Alguns sistemas, como o Firebase e certas APIs de Android, usam milissegundos. Outros, como o padrão POSIX, usam segundos. Confundir os dois produz datas em anos diferentes de 2100. Minha regra simples é sempre verificar a ordem de grandeza: se o número tiver 10 dígitos é segundos, 13 dígitos é milissegundos. Se precisar de mais segurança, armazene o timestamp junto com uma flag de unidade. Custa quase nada e evita meia dúzia de tickets de suporte.

Formatos legíveis para interfaces

Aqui as coisas ficam culturais. Nos EUA prevalece MM/DD/YYYY. Na maior parte da América Latina e Europa, DD/MM/YYYY. O Brasil usa DD/MM/YYYY e, quando inclui hora, costuma-se escrever 14/07/2025 16:30. O formato com nome do mês, como 14 de julho de 2025, elimina ambiguidade, mas ocupa mais espaço e é mais trabalhoso de normalizar em lote. Para APIs, prefira sempre ISO 8601 no wire e formate apenas na camada de apresentação. Já vi equipe integrar um sistema chinês que usava YYYYMMDD sem separadores em URLs, e a primeira integração quebrou porque o framework assumiu traços. A correção foi tratar Those endpoints com serializadores customizados.

Fusos horários e a armadilha dos nomes

Evite abreviações como BRT, EST, CET. Elas são ambíguas e existem múltiplos lugares que compartilham siglas idênticas. Use identificadores IANA como America/Sao_Paulo ou Europe/Lisbon. O .NET transforma isso com TimeZoneInfo.FindSystemTimeZoneById, e o Java usa ZoneId.of. Bancos de dados como PostgreSQL e MySQL também suportam o formato completo. O detalhe que poucos mencionam: mudanças de horário de verão. Um país pode abandonar o DST e seu offset muda permanentemente. Ter dados históricos sem fuso IIANA gera inconsistência em auditorias. Minha correção foi manter sempre o deslocamento original no momento do evento e usar o fuso apenas para conversões futuras, nunca para relatórios históricos.

Outros formatos que ainda aparecem no campo

RFC 2822 ainda rodando em cabeçalhos de e-mail, como Mon, 14 Jul 2025 16:30:00 +0000. .NET lê com DateTime.ParseExact usando o formatador RFC1123. Ctambém expõe DateTime.ToString("r") para gerar essa string de formapadronizada. Formato americano longo: Monday, July 14, 2025. Útil para relatórios gerenciais, inadequado para troca de dados. Você perde tempo convertendo e ganha erros de localização. Formato compacto com letras fixas: yyyyMMdd, muito usado em nomes de arquivo e logs. Funciona bem para ordenação lexicográfica, mas não carrega horário nem fuso, então é ruim para agregações temporais sensíveis.

Recomendações práticas que economizam dor de cabeça

Armazene tudo em UTC com ISO 8601 ou Unix timestamp. Nunca misture os dois no mesmo sistema. Para interfaces, deixe o usuário escolher o formato de exibição, mas mantenha o padrão interno imutável. Valide entrada com parsing estrito, rejeitando formatos que não correspondam ao esperado. E se estiver migrando dados entre sistemas, escreva um script de double-parse que tente múltiplos formatos e registre falhas; isso reduz o tempo de saneamento de dias para horas, dependendo do volume. Citar alguns formatos de data e hora num documento técnico é simples. O difícil é garantir que todos os sistemas que você integra concordem com exatamente qual deles está sendo usado. Quando esse acordo falha, os bugs não aparecem de imediato. Eles aparecem meses depois, em relatórios fechados, com datas que parecem certas mas estão deslocadas por um ou dois dias. Por isso eu insisto: padronize na origem, formate na chegada, e nunca confie em suposições de localidade.