Fuso horário no Power Query: padronize datas de eventos

Tratar fuso horário no Power Query exige separar o instante em que um evento ocorreu da hora exibida para uma operação. A mesma entrega pode cair em datas diferentes conforme a referência usada. Remover o fuso ou converter o texto cedo demais pode atribuir o evento ao dia errado.

Este roteiro prepara registros de eventos para comparação entre sistemas. O resultado deve preservar o instante original e produzir uma data operacional definida pelo negócio. A análise inclui offsets, que são diferenças numéricas em relação ao UTC, e limitações de horários sem informação de origem.

1. Identifique a origem do fuso horário no Power Query

Confira se a coluna informa UTC, horário local sem fuso ou data e hora com offset. UTC é o Tempo Universal Coordenado, usado como referência comum. Um texto terminado em Z indica essa referência em formatos que adotam a convenção; confirme o contrato da fonte antes de converter.

Guarde uma amostra dos valores originais e a documentação do sistema. Um campo chamado “DataEntrega” não revela sozinho como o horário foi registrado. Se a informação estiver ausente, solicite sua definição ao responsável pela fonte e marque os eventos como pendentes de normalização.

2. Preserve o valor original durante a preparação

Mantenha a coluna recebida e crie colunas derivadas para o processamento. Isso permite comparar a entrada com o resultado e identificar onde um deslocamento ocorreu. Não substitua imediatamente a origem por uma data simples, pois o horário e a diferença de fuso serão perdidos.

Separe também data de ocorrência e data de registro no sistema. Um evento pode ser informado horas depois de acontecer. Essa diferença é de processo, não de fuso. Misturar os dois problemas dificulta investigar atrasos de registro e pode produzir durações aparentemente negativas.

3. Atribua um offset somente quando ele for conhecido

Um valor do tipo datetime contém data e hora sem offset. Quando a fonte confirma a referência, use uma transformação explícita para associá-la. A função DateTime.AddZone acrescenta a informação de fuso sem deslocar a hora, conforme a referência oficial da Microsoft, consultada em 7 de outubro de 2026.

Em um exemplo hipotético, 10h registradas numa origem confirmada como UTC−3 representam 13h UTC. Atribuir UTC diretamente ao valor original criaria outro instante. Não use o offset da máquina que executa a atualização como substituto da informação do evento.

4. Converta os instantes para uma referência comum

Após obter um valor com offset, derive a referência UTC para comparar sistemas. A função DateTimeZone.ToUtc faz essa conversão, segundo a documentação da Microsoft, consultada em 7 de outubro de 2026. Preserve a coluna original e identifique claramente a coluna normalizada.

Compare eventos equivalentes de duas fontes. Num exemplo hipotético, 10h com offset −3 e 13h com offset zero representam o mesmo instante. Se a união dos registros os tratar como ocorrências diferentes apenas pelo texto, revise a chave usada para detectar duplicidades.

Para uma coluna HoraLocal do tipo datetime, uma expressão ilustrativa é DateTimeZone.ToUtc(DateTime.AddZone([HoraLocal], -3)). Ela só se aplica quando a origem confirma offset −3 para todos os registros tratados. Execute-a primeiro sobre a tabela de teste e confira o instante UTC esperado antes de aplicar à carga completa.

5. Derive a hora operacional depois da normalização

Escolha a referência usada pelo negócio para agrupar eventos. A função DateTimeZone.SwitchZone muda a representação para um offset informado, conforme a referência oficial, consultada em 7 de outubro de 2026. Use-a sobre valores que já têm componente de fuso.

Em um exemplo hipotético, um evento às 01h30 UTC corresponde a 22h30 do dia anterior numa referência de offset −3. Extraia a data operacional somente após essa conversão. Uma data derivada primeiro em UTC e depois rotulada como local manteria o dia incorreto.

6. Não confunda offset fixo com zona regional

Um offset numérico representa a diferença aplicada àquele instante. Ele não descreve sozinho todas as regras históricas de uma região. Se a operação depende de mudanças de offset ao longo do tempo, a transformação precisa receber uma referência válida para a data e a origem.

Não aplique um único offset a todo o histórico sem confirmar essa condição. Prefira o instante e o offset fornecidos pelo sistema de origem ou uma conversão feita por uma camada que conhece as regras necessárias. Registre a limitação quando o histórico não permitir recuperar a referência correta.

7. Monte um teste com viradas de dia e mês

Crie uma tabela pequena com instantes antes e depois da meia-noite na referência operacional. Inclua uma virada de mês e dois registros do mesmo instante com offsets diferentes. Para cada linha, anote o UTC esperado, a hora operacional e a data esperada.

Em um exemplo hipotético, 02h UTC no primeiro dia do mês pertence às 23h do último dia do mês anterior com offset −3. Esse caso deve entrar no fechamento operacional anterior. Um teste feito apenas ao meio-dia não revela esse tipo de erro de agrupamento.

8. Separe a data de negócio das outras datas do modelo

Use nomes como DataEntregaOperacional e InstanteEntregaUTC. O artigo de múltiplas datas no Power BI ajuda a organizar datas com papéis diferentes. A conversão de fuso resolve a referência temporal; o relacionamento do calendário resolve qual evento o filtro analisa.

Para medir duração entre etapas, compare instantes normalizados antes de remover o componente necessário ao cálculo. Para agrupar por dia, use a data operacional aprovada. Exiba essa convenção na página para que um usuário não compare um total local com um relatório de origem agrupado em UTC.

9. Valide a atualização no ambiente de destino

Execute os mesmos casos no ambiente em que a carga será usada. Evite transformações que dependem implicitamente da hora local da máquina. Registre os resultados esperados numa consulta de conferência para detectar mudanças de formato ou referência quando a fonte for atualizada.

Confira erros de conversão e valores sem fuso numa fila separada. Não substitua falhas por uma data arbitrária para conseguir carregar a tabela. Mostre quantidade de registros pendentes e período afetado, permitindo avaliar o impacto antes de usar o resultado num fechamento ou indicador de prazo.

10. Reconcilie os indicadores após a mudança

Compare totais diários antes e depois da conversão e investigue os registros que trocaram de dia. O guia de OTIF e entregas no prazo exemplifica uma análise em que a definição temporal importa. Verifique também a referência da promessa antes de compará-la com a entrega.

O modelo editável de Logística pode receber dados preparados para a operação. Esta normalização exige conhecer o formato e a referência das fontes. Preserve instantes para auditoria, derive datas operacionais explicitamente e libere a mudança somente após validar os casos que atravessam dias e períodos de fechamento.

Documente uma amostra de eventos deslocados corretamente e uma de valores rejeitados por falta de referência. A equipe deve conseguir reconstruir cada decisão usando o dado original. Isso mantém a transformação explicável mesmo quando a pessoa responsável pela integração muda.