Português (Brasil)

Ferramentas para desenvolvedores · Conversor de carimbo de data/hora Unix

Os fusos horários não são compensações: o banco de dados IANA tz e por que ele é importante

· Fundo

carimbos de data/hora fusos horários APIs do navegador

Um caminho de zona nomeada produzindo diferentes deslocamentos por dois instantes
Ilustração vetorial original ToolAcre

Um deslocamento é um número; um fuso horário é um histórico de números e as regras para quando eles mudam. Este post explica a diferença, apresenta o banco de dados IANA tz que o codifica e mostra por que os conversores dependem dele para a leitura local.

A reunião que avançou uma hora — um deslocamento armazenado de +02:00 que estava certo em julho e errado em dezembro

Um `+02:00` fixo salvo ao lado de uma reunião de julho pode ser uma leitura fiel para aquele instante e ainda assim falhar como regra para dezembro. O deslocamento é um resultado; a zona é o contexto de regras capaz de produzir resultados em datas diferentes. Armazenar um como se fosse o outro congela um instantâneo.

A linha local de ToolAcre solicita ao Intl para formatar cada data e solicita um deslocamento numérico curto. Ele não adiciona uma constante de configuração à época. Esse design permite que a regra aplicável ao ambiente influencie cada instante separadamente.

Deslocamento versus zona — uma distância fixa de UTC versus uma região nomeada com regras DST e um histórico de alterações

Um deslocamento indica a que distância um relógio renderizado está de UTC em um instante. Uma região nomeada pode conter uma sequência de regras de compensação e alterações históricas. A época em si não carrega nenhum dos dois. Esses conceitos devem ocupar campos separados quando uma aplicação precisa de um evento e de uma programação baseada em local.

Para um evento imutável, armazenar o instante pode ser suficiente. Para “abrir às 09:00 nesta região todos os dias”, retenha a zona nomeada porque as instâncias futuras deverão ser resolvidas a partir do momento da parede. A reutilização do deslocamento de ontem trata uma regra dinâmica como uma propriedade numérica permanente.

O banco de dados IANA tz — Nomes da Área/City, por que é um registro de decisões políticas e com que frequência é atualizado

A pasta de trabalho nomeou o banco de dados IANA, origem política e frequência de atualização. A implementação relata um nome de zona no estilo IANA de `resolvedOptions()`, mas não expõe uma versão do banco de dados, agendamento de atualização ou pacote de origem. Esses detalhes não são afirmados aqui.

Esta limitação afeta a reprodução. Se a saída da data antiga for diferente entre as máquinas, registre a sequência da zona e as versões da plataforma; não reivindique qual conjunto de regras é mais recente apenas com base no relógio. Uma zona nomeada melhora a questão, mas o conversor não é um inspetor de dados de fuso horário.

Os aplicativos que precisam de resultados históricos reproduzíveis devem controlar sua dependência de dados de zona e testar datas representativas. Depender de um ambiente de navegador não especificado delega essa reprodutibilidade.

A procedência da regra de zona nomeada e a cadência de atualização não são expostas por esta implementação

ToolAcre solicita ao navegador sua zona local e formata por meio do Intl. O repositório não estabelece se as regras vieram do sistema operacional, do pacote do navegador ou de outro componente de tempo de execução. Ele detecta falhas e recua com segurança, em vez de expor a arquitetura interna.

Consequentemente, “local” significa o ambiente selecionado pelo navegador no momento da conversão. Alterar a configuração do dispositivo pode alterar a saída sem alterar a época. Para trilhas de auditoria, preserve UTC e a contagem bruta; use a exibição local como contexto em vez de armazenamento canônico.

O fallback para ISO em caso de falha do formatador preserva um instante, mas perde a apresentação local solicitada. Os consumidores devem tratar isso como um contexto de exibição reduzido, e não como uma data alterada.

O navegador seleciona e formata sua zona local; a fonte de suas regras não é afirmada

Escolha dois instantes UTC com seis meses de intervalo, como `2025-01-15T12:00:00Z` e `2025-07-15T12:00:00Z`, converta-os em segundos e inspecione as linhas locais em um dispositivo. Registre se o deslocamento numérico é diferente. A observação é válida para a zona e ambiente exibidos.

A pasta de trabalho prescreveu compensações Europe/Berlin, mas essas regras de zona nomeada não foram lidas na implementação. Este exercício reproduzível evita uma tabela sem suporte enquanto ensina a mesma distinção: uma consulta de zona, dois instantes e potencialmente dois resultados de deslocamento.

Se os deslocamentos corresponderem, a observação ainda será informativa: aquela zona configurada não expôs uma diferença sazonal nos instantes escolhidos naquele ambiente.

Exemplo resolvido: observe uma zona do navegador em duas datas em vez de codificar as regras de Berlim

O painel solicita `timeZoneName: "shortOffset"`, o que favorece um relacionamento numérico como GMT+1 em vez de uma abreviatura regional. Essa escolha reduz a dependência de rótulos cujo significado pode variar de acordo com o contexto, embora a formatação Intl exata continue sendo saída da plataforma.

Para dados armazenados, use identificadores de zona canônicos definidos pela biblioteca escolhida do aplicativo em vez de exibir abreviações. Uma etiqueta curta voltada para o usuário pode ser útil, mas não deve se tornar a chave que reconstrói um cronograma futuro.

Os deslocamentos numéricos permanecem inequívocos como aritméticos em um instante. Sua limitação é a falta de identidade da regra, e não a incapacidade de mapear a leitura daquele relógio para UTC.

As abreviaturas são evitadas nos dados armazenados; o formatador solicita um deslocamento numérico curto

O agendamento futuro recorrente precisa de lacunas, sobreposições e tratamento de políticas que este conversor não oferece. Ele começa com uma data ou época resolvida e a renderiza. Não escolhe entre dois horários locais repetidos nem repara um horário inexistente.

Use uma biblioteca de agendamento com reconhecimento de zona cujo comportamento é testado de acordo com seus requisitos e, em seguida, inspecione as ocorrências resolvidas aqui, se for útil. Separar a resolução da exibição evita que um conversor simples se torne um agendador acidental com política de borda indefinida.

A saída do agendador pode então ser armazenada como uma época para execução, mantendo a zona e a intenção original do tempo de parede para recálculo ou explicação futura.

Conclusão: armazene instantes como épocas, armazene locais como nomes de zonas - e como o conversor de carimbo de data / hora Unix usa a zona do seu navegador para a leitura local

Armazene instantes como unidades de época explícitas ou strings canônicas UTC e armazene zonas nomeadas quando o local em si for importante. Um deslocamento pode acompanhar uma saída para explicação, mas não substitui nenhum dos campos. As linhas UTC e locais de ToolAcre demonstram essa separação.

Quando um resultado local o surpreender, verifique o rótulo da zona, instantâneo e deslocamento antes de alterar os dados. Um patch de deslocamento fixo pode fazer com que uma data pareça certa e outra errada. O modelo durável mantém o evento estável e permite que uma regra de zona verificada forneça seu mostrador de relógio.

Este modelo também suporta viagens: um usuário pode visualizar um instante armazenado em uma nova zona local sem reescrever o evento ou perder seu contexto de agendamento original.