Publié dans Cho Hisabi. J'étais tellement surpris et irrité.
Découvert lors de la migration d'un système Java d'Amazon Linux vers Amazon Linux 2.
Dans Amazon Linux 2, exécutez la commande suivante pour définir le fuseau horaire du système.
#timedatectl set-timezone "Asia/Tokyo"
Normalement, tout devrait être OK, et même si vous recherchez sur le net, seul Cocomade est écrit dans les articles des séries Amazon Linux 2 et CentOS 7.
Cependant, TimeZone ne peut pas être acquis correctement dans le programme Java et devient UTC.
échantillon:
TimeZoneInfo.java
import java.util.Calendar;
class TimeZoneInfo {
public static void main(String[] args) {
Calendar cal = Calendar.getInstance();
System.out.println(cal.getTimeZone());
System.out.println(System.getProperty("user.timezone"));
}
}
Résultat de l'exécution:
sun.util.calendar.ZoneInfo[id="UTC",offset=0,dstSavings=0,useDaylight=false,transitions=0,lastRule=null]
UTC
Il y a plusieurs façons de le gérer (Il a fallu beaucoup de temps pour le trouver)
-Duser.timezone = Asia / Tokyo``` à la ligne de commande java / etc / sysconfig / clock```, qui était la méthode de réglage standard à l'époque d'Amazon Linux.etc. Je pense qu'il y a des problèmes.
--timedatectl réécrira / etc / localtime, mais pas `` `` / etc / sysconfig / clock. (En premier lieu, il semble qu'il n'y ait pas de fichier lui-même dans CentOS 7 ...)
--Java ne regarde pas / etc / localtime```. Il semble que cela dépend de la version. Cela peut être un changement dans le comportement de la glibc, mais la cause détaillée est inconnue.
--Depuis qu'il est devenu un système systemd, / etc / sysconfig n'est pas souvent mentionné, mais l'héritage du passé demeure, alors veuillez considérer un peu plus la compatibilité. .. .. ..
Quelle est la méthode de réponse la plus correcte (ou devrait être)? .. .. .. Ou plutôt, standardisez les paramètres de fuseau horaire.
Recommended Posts