Fuso horário no Power Automate: utcNow, convertTimeZone e nomes do Windows
O fluxo gravou 11:30 e a pessoa tinha pedido 08:30? Quase sempre é o fuso: o Power Automate trabalha em UTC e a conversão para Brasília precisa ser feita por você, com o nome de fuso certo. Veja como fazer e onde as pessoas erram.
O ponto de partida: utcNow() é UTC
A função utcNow() devolve o momento atual em UTC, com o Z no final. A documentação da Microsoft mostra o formato padrão assim: 2025-09-25T05:18:31.3384797Z. Não existe "hora local" automática: se o seu fluxo roda para uma equipe em Brasília, quem escreve a conversão é você.
No teste que fiz no Power Automate (fluxo de teste, sem conectores, em 02/11/2026), formatDateTime sobre uma data UTC, sem informar formato, devolveu 2026-11-02T08:05:09.0000000Z. O Z continua lá. Ou seja: se você grava esse valor direto em um e-mail ou em uma coluna de texto, a pessoa lê um horário UTC, que em Brasília está 3 horas adiantado.
convertTimeZone: o jeito mais usado
Pela documentação, a sintaxe é convertTimeZone('<data>', '<fusoOrigem>', '<fusoDestino>', '<formato>'?). O formato é opcional. Para converter o agora de UTC para Brasília e já deixar legível:
convertTimeZone(utcNow(), 'UTC', 'E. South America Standard Time', 'dd/MM/yyyy HH:mm')
Executado no Power Automate com uma data fixa, para o resultado ser reproduzível:
convertTimeZone('2026-11-02T11:30:00Z', 'UTC', 'E. South America Standard Time', 'dd/MM/yyyy HH:mm')
resultado: 02/11/2026 08:30
Sem o parâmetro de formato, o resultado vem no padrão ISO, mas sem o Z. Executado:
convertTimeZone('2026-07-15T12:00:00Z', 'UTC', 'E. South America Standard Time')
resultado: 2026-07-15T09:00:00.0000000
Esse texto já está em horário de Brasília. A documentação de convertFromUtc diz o mesmo: o resultado vem sem o deslocamento do fuso. Se você passar esse valor adiante como se fosse UTC, o próximo passo vai tratá-lo como UTC e a hora fica errada.
convertFromUtc e convertToUtc
Quando a origem é sempre UTC, convertFromUtc é mais curta, porque não pede o fuso de origem:
convertFromUtc('2026-11-02T11:30:00Z', 'E. South America Standard Time', 'dd/MM/yyyy HH:mm')
Ela faz o mesmo que o convertTimeZone acima. Eu não executei esta forma no fluxo de teste; o comportamento está descrito na documentação da Microsoft, com o exemplo convertFromUtc('2018-01-01T08:00:00.0000000Z', 'Pacific Standard Time') resultando em 2018-01-01T00:00:00.0000000.
O caminho inverso é convertToUtc: ele pega uma data no horário local (por exemplo, digitada por uma pessoa em um formulário) e leva para UTC. Exemplo da documentação: convertToUtc('01/01/2018 00:00:00', 'Pacific Standard Time') devolve 2018-01-01T08:00:00.0000000Z. Use quando precisar comparar com utcNow() ou gravar em UTC.
Nomes de fuso: do Windows, não da IANA
Os três conversores recebem o nome de fuso do Windows, listado na página "Default Time Zones" da Microsoft. Nomes como America/Sao_Paulo não são os esperados. A página lista, para o Brasil, E. South America Standard Time, com UTC-03:00 e a descrição "Brasilia". A documentação da função ainda avisa que, em convertTimeZone, "você pode ter de remover a pontuação" do nome. Se der erro, teste o nome em uma ação Compose isolada.
Resultados reais de um fluxo de teste, convertendo 2026-07-15T12:00:00Z com formato HH:mm:
E. South America Standard Time(Brasília): 09:00SA Eastern Standard Time(Fortaleza): 09:00Bahia Standard Time(Salvador): 09:00SA Western Standard Time(Manaus): 08:00Central Brazilian Standard Time(Cuiabá): 08:00SA Pacific Standard Time(Rio Branco): 07:00UTC: 12:00
Moral: o Brasil tem fusos diferentes, e "Brasília" não serve para quem está em Manaus ou Rio Branco. Se o fluxo atende o país todo, guarde o fuso de cada unidade ou usuário em uma coluna, em vez de fixar um nome na expressão.
Horário de verão: o que muda e o que não muda
O nome "Standard Time" engana: as conversões respeitam o horário de verão dos países que o adotam. No mesmo teste, com 2026-07-15T12:00:00Z e 2026-01-15T12:00:00Z:
- Nova York (
Eastern Standard Time): 08:00 em julho e 07:00 em janeiro - Londres (
GMT Standard Time): 13:00 em julho e 12:00 em janeiro - Sydney (
AUS Eastern Standard Time): 22:00 em julho e 23:00 em janeiro
Isso quer dizer que a diferença entre Brasília e Nova York, por exemplo, não é fixa: em julho Nova York fica 1 hora mais perto de Brasília que em janeiro. Por isso converta sempre com a data real do evento, nunca somando um número fixo de horas.
E o Brasil? O horário de verão foi encerrado no território nacional pelo Decreto nº 9.772, de 25 de abril de 2019, cujo artigo 1º diz que "fica encerrada a hora de verão no território nacional". No teste em 02/11/2026, a conversão de 11:30 UTC para Brasília deu 08:30, ou seja, UTC-3, sem ajuste. Se o seu fluxo trata datas anteriores a 2019, a regra da época não é a de hoje, e a conversão correta deve vir do fuso, não de um cálculo manual. Confira sempre a legislação vigente na fonte oficial; este guia não é orientação jurídica.
Erros comuns
1. Somar ou subtrair 3 horas na mão
addHours(utcNow(), -3) dá o horário certo de Brasília hoje porque não há horário de verão no país, mas não serve para Nova York, Londres ou qualquer fuso que muda, e quebra se a regra mudar. Prefira convertTimeZone.
2. Tratar o horário local como se fosse UTC
Uma pessoa informa "02/11/2026 08:30" em um formulário. Se você passa esse texto para convertTimeZone(..., 'UTC', 'E. South America Standard Time'), o fluxo entende que 08:30 é UTC e devolve 05:30 (cálculo por UTC-3, não executado). O certo é a origem ser o fuso da pessoa, ou usar convertToUtc.
3. Reconverter um resultado sem Z
Como visto acima, o resultado sem formato vem sem Z e já está no fuso de destino. Converter de novo "de UTC" desloca a hora mais 3 horas para trás.
4. Formatar antes de calcular
Transformar a data em texto cedo demais faz você comparar textos, não datas. Mantenha o valor em ISO enquanto o fluxo calcula e use formatDateTime na última ação.
5. Códigos de formato curtos
No teste, formatDateTime com o formato H falhou: o erro diz que um formato de uma letra precisa ser um especificador padrão válido (como d ou g) ou um padrão personalizado (como MMMM dd, yyyy). Use HH para a hora de 00 a 23. Também lembre que mm é minuto e MM é mês: no teste, mm sobre 08:05:09 deu 05 e MM deu 11.
6. Dia e mês trocados na leitura
Antes de converter, a data precisa ser lida certo. No teste, parseDateTime('03/04/2026', 'pt-BR') deu 3 de abril (2026-04-03) e, com 'en-US', 4 de março (2026-03-04). Informe a cultura sempre que a data vier digitada.
Receita pronta para um e-mail em horário de Brasília
- Guarde o valor original em UTC (o de
utcNow()ou o da coluna do SharePoint). - Na hora de mostrar, use
convertTimeZone(valor, 'UTC', 'E. South America Standard Time', 'dd/MM/yyyy HH:mm'). - Se alguém digitou a data, leia com
parseDateTimee a cultura certa e converta comconvertToUtcantes de gravar. - Teste com uma data de julho e outra de janeiro, para pegar problemas de horário de verão em fusos estrangeiros.
Para conferir o resultado sem rodar o fluxo, use o conversor de fuso horário do Me Ajuda Flow, que mostra a mesma hora em vários fusos e o nome do Windows de cada um. Para escolher o formato do texto, veja também o construtor de formato de data e a ferramenta de datas.