Pular para o conteúdo principal

[NÃO] Horário de verão



Horário de verão - problema

No dia 02 para 03 de Novembro de 2019, o Java estava programado para trabalhar no horário de verão Brasileiro. Então caso você rode o código abaixo, vai perceber que a hora estará adiantada.
public static void main(String[] args) {
    System.out.println(new Date());
}
Mon Nov 04 10:52:50 BRST 2019

Sendo que a data do sistema é:
Mon Nov  4 09:52:50 -03 2019

Se este não é o seu caso, pode ficar tranquilo que seu Java está atualizado com as definições de TimeZone.

Solução

Caso você não saiba, o Java mantem uma base de dados de TimeZone local que não é atualizada automaticamente. Então como o horário de verão já estava planejado e embutido na JRE, a atualização precisa ser feita de forma manual.
Atenção: O procedimento abaixo pode não funcionar para todas as versões do Java ou variações de distribuição.

Abaixo o processo para atualização:

1 - Faça o download da ferramenta tzupdater:

2 - Descompacte o conteúdo do zip.

3 - Exporte uma variável para facilitar a execução do comando posterior:
export TZ_UPDATER_JAR_ROOT=/home/Download/tzupdater-2.3.0

4 - Rode este script dentro do bin do jdk desejado:
cp -v $TZ_UPDATER_JAR_ROOT/tzupdater.jar . && chmod -v 777 tzupdater.jar && java -jar tzupdater.jar -l https://www.iana.org/time-zones/repository/tzdata-latest.tar.gz

O script acima copia o jar para o diretório bin do JDK e executa a atualização.

jEnv:

Caso você utilize o jEnv (ver neste post), você precisará criar uma versão local dentro do diretório bin do JDK. Caso contrário estará executando o Java configurado como global. Obrigado ao amigo Rafael Buzzi pela dica.




Siga no twitter para ficar informado dos novos posts:



Referências:


Comentários

Postagens mais visitadas deste blog

Java Records

  Java Records Imutável, Simples e limpa Esta funcionalidade da linguagem apareceu pela primeira vez na versão 14 como experimental e assim continuou até a versão 15 . Agora liberada de forma definitiva no Java 16 . O objetivo é ser possível ter classes que atuam como portadores transparentes de dados imutáveis. Os registros podem ser considerados tuplas nominais. Ou seja, após criado, um record não pode mais ser alterado. Records oferece uma uma sintaxe compacta para declarar classes que são portadores transparentes para dados imutáveis superficiais visando reduzir significamente o detalhamento dessas classes e irá melhorar a capacidade de leitura e manutenção do código. Vamos seguir um exemplo de uma classe chamada Pessoa . O primeiro exemplo vamos utilizar o modo tradicional. public class Pessoa { private String nome; private int idade; public Pessoa (String nome, int idade) { super (); this .nome = nome; this .idade = idade; } public String getNo

Java 8 ao 18: Mudanças mais importantes na plataforma Java

    Vamos rever muitas das mudanças mais importantes na plataforma Java que aconteceram entre a versão 8 (2014) e 18 (2022)   O Java 8 foi lançado em março de 2014 e o Java 18 em março de 2022. São 8 anos de progresso, 203 JEPs (JDK Enhancement Proposals ), entre essas duas versões. Neste post, revisaremos as mudanças mais importantes e discutiremos os benefícios e desafios da adoção de versões mais recentes do JDK para novos aplicativos e para os mais antigos compilados com versões mais antigas. Desde a versão 9, o Java tem novos recursos a cada 6 meses e é muito difícil acompanhar essas novas mudanças. A maioria das informações na internet descreve as mudanças entre as duas últimas versões do Java. No entanto, se você estiver em uma situação semelhante à minha, não está usando uma das versões mais recentes do Java, mas uma das várias versões anteriores (Geralmente 8 ou 11 que são as versões de suporte estendido). Então é útil saber quais novos recursos foram adicionados d

O suporte de longo prazo e o que o LTS significa para o ecossistema Java

A arte do suporte de longo prazo e o que o LTS significa para o ecossistema Java Aqui está o que o Java 17 tem em comum com o Java 11 e o Java 8. Em junho de 2018, há pouco mais de três anos, a Oracle e outros participantes do ecossistema Java anunciaram uma mudança no modelo de cadência de lançamento para Java SE. Em vez de ter um lançamento principal planejado a cada dois ou quatro anos (que geralmente se torna de três a quatro anos), um novo modelo de lançamento de recursos de seis meses seria usado: a cada três anos, um lançamento seria designado como Long-Term Support (LTS) e receba apenas atualizações trimestrais de segurança, estabilidade e desempenho. Esse padrão foi emprestado descaradamente do modelo de lançamento do Mozilla Firefox, mas o ajustou para ficar mais alinhado com os requisitos de uma plataforma de desenvolvimento. A primeira versão do Java lançada sob esse modelo foi o Java SE 11. O lançamento do Java SE 17, o segundo lançamento do LTS sob o novo