Como criar uma data com um timezone específico em JavaScript

Neste artigo você vai aprender a como criar uma data com um timezone específico em JavaScript, ou seja, de qualquer local do mundo

Fala programador(a), beleza? Bora aprender mais sobre datas e JavaScript!

Para resolver o nosso problema temos uma função específica, que é a toLocaleString do objeto Date

Esta função nos permite escolher formato da data, por exemplo: formato brasileiro ou americano

E também o fuso horário que precisamos, que também é conhecido com timezone

Veja duas aplicações específicas desta função:

const myBrazilianDate = new Date().toLocaleString("pt-BR", {timeZone: "America/Sao_Paulo"})

const myDate = new Date().toLocaleString("en-US", {timeZone: "America/New_York"})

console.log(myBrazilianDate) // "14/03/2022 16:41:57"

console.log(myDate) // "3/14/2022, 3:41:57 PM"

Formação Recomendada

Formação Claude Code

Domine Claude Code do absoluto zero até o avançado

• 120 aulas
• 4 projetos
• 9h 45min

Conhecer formação

Aqui temos uma data do fuso horário brasileiro sendo criada, e uma data do fuso de Nova York

Note que no primeiro argumento passamos o padrão que a data deverá ser transmitida, no primeiro caso foi configurado pt-BR

Isso nos dá um formato dia/mês/ano hora:minuto:segundo, e nas horas não temos AM e PM, e sim de 0 a 23, que é o padrão que o Brasil utiliza

Conclusão

No artigo de hoje você aprendeu a como criar uma data com um timezone específico em JavaScript

Utilizamos o objeto Date e a função toLocaleString, ela nos permite configurar uma data com um formato e um timezone específico

Confira nossos cursos gratuitos no Youtube, com vídeos todos os dias! Se inscreva e ative o sininho para receber as notificações e aprender mais ainda sobre desenvolvimento web!

Veja também nosso catálogo de cursos na Udemy, todos com exercícios e projetos práticos, nas mais diversas tecnologias. O link acima contém um cupom de desconto para os cursos!

O toLocaleString devolve texto, não uma data nova:

Repara no que saiu no console ali em cima

É uma string, já formatadinha pra jogar na tela

Ou seja: serve pra EXIBIR, não pra continuar fazendo conta

Tome cuidado! Se você guardar esse retorno numa variável e depois tentar comparar com outra data, ou somar dias, vai dar ruim, porque texto não tem os métodos do objeto Date

A regra prática é simples: mantenha o objeto Date pra manipular, e chame o toLocaleString só na hora de mostrar pro usuário

faça o teste! Compara o retorno de new Date() com o retorno do toLocaleString e vê a diferença na hora 🙂

Por que a data muda quando o código sai da sua máquina?

Essa é a pegadinha clássica

Na sua máquina roda certinho, aí você sobe pro servidor e o horário aparece diferente

O motivo: quando você NÃO passa o timeZone, quem decide o fuso é o ambiente onde o código está rodando

No seu computador o ambiente é o seu fuso, no navegador do usuário é o fuso dele, e num servidor é o fuso que o servidor estiver configurado

Por isso o segundo argumento com o timeZone é tão importante: ele tira a decisão do ambiente e coloca a decisão no seu código

Se a data precisa sair sempre no fuso de São Paulo, independente de onde rode, você diz isso explicitamente

const myBrazilianDate = new Date().toLocaleString("pt-BR", {timeZone: "America/Sao_Paulo"})

Sem isso, você está confiando na configuração da máquina, e configuração de máquina muda 😛

O formato do timezone: Região/Cidade

Olha os dois exemplos que usamos: America/Sao_Paulo e America/New_York

Percebe o padrão? É sempre região barra cidade, com underline no lugar do espaço

Não é sigla, não é o nome do país e não é o horário em si, é o identificador daquela região

E tem um motivo bom pra ser assim: o identificador carrega as regras daquele lugar, então você descreve ONDE, e a formatação resolve o resto

Se você digitar errado, o JavaScript reclama na hora, então na dúvida copia o identificador da cidade que você precisa e testa no console antes de sair espalhando pelo projeto

Exibir num fuso, guardar num só:

Um conselho que vale mais que o código em si

Escolha UM padrão pra armazenar a data (no banco, na API, no que for) e trate fuso só na hora de exibir

Se cada tela salvar a data já formatada no fuso do usuário, você perde a referência e depois não consegue nem ordenar direito

Pensa assim: o dado guardado é o instante, o toLocaleString é a roupa que ele veste pra aparecer

Guardar a roupa no lugar do instante é o começo de um bug bem chato de achar