Gestion des fuseaux horaires avec Java

Avant qu'il ne grandisse sur le sujet

Lorsqu'il s'agit de fuseaux horaires en utilisant java.util.Date en Java, je pense qu'il est courant que la date et l'heure soient le temps écoulé (millisecondes) entre l'heure et le fuseau horaire gérés par GMT. , Ici, nous supposons que la date, l'heure et le fuseau horaire sont séparés pour une raison quelconque. Par exemple, cela ressemble à ceci

Lorsque cela est affiché par System.out.println etc., la valeur détenue par le type Date semble étrange comme indiqué ci-dessous. En d'autres termes, je veux que 15h00 soit l'heure d'Australie / Sydney, mais pour une raison quelconque, c'est un fuseau horaire local. C'est comme ça.

Thu Dec 01 15:00:00 JST 2016

sun.util.calendar.ZoneInfo[id="Asia/Tokyo",offset=32400000,dstSavings=0,useDaylight=false,transitions=10,lastRule=null]

Aussi, ** Si vous utilisez la conversion effectuée ici, vous exécuterez un bogue, donc d'un autre côté, n'atteignez pas cette logique en tant qu'enseignant. ** Si vous trouvez une solution, je la posterai à nouveau. Je ne sais pas si la situation est évitée.

Sujet principal

Quoi qu'il en soit, je réfléchis à la façon de les conserver en tant que données correctes lorsque la situation ci-dessus se produit. Éviter de telles situations peut être la meilleure solution.

Pour Java 8 ou version antérieure

C'est un petit code délicat. C'est une mesure minutieuse pour le convertir en une chaîne de caractères.

TimezoneConversion.java

    static Date convertWithBeforeJava7(Date dateTime, TimeZone timeZone) throws ParseException {
        String format = "yyyy/MM/dd HH:mm:ss.SSS";
        SimpleDateFormat local = new SimpleDateFormat(format);
        SimpleDateFormat convert = new SimpleDateFormat(format);
        convert.setTimeZone(timeZone);
        return convert.parse(local.format(dateTime));
    }

Java8

Je ne peux pas m'y habituer, mais je l'ai également essayé dans les classes Java 8. C'est rafraîchissant en quelque sorte, mais j'ai aussi l'impression que je vais prendre la peine de revenir au type Date.

résultats de test

J'ai fait deux types de tests. L'entrée est la suivante.

Condition environnementale

contribution

Veuillez noter que ce n'est pas un test suffisant. Le résultat est le suivant.

java.lang.AssertionError: It would be same date
Expected: is <Sun Oct 02 17:00:00 EST 2016>
     but: was <Sun Oct 02 18:00:00 EST 2016>

	at org.hamcrest.MatcherAssert.assertThat(MatcherAssert.java:20)
	at org.junit.Assert.assertThat(Assert.java:956)
	at com.nekoscape.java.sample.TimezoneConversionTest.convertWithOtherTimezone_test_for_Java8Method(TimezoneConversionTest.java:76)
(réduction)

java.lang.AssertionError: It would be same date
Expected: is <Sun Oct 02 17:00:00 EST 2016>
     but: was <Sun Oct 02 18:00:00 EST 2016>

	at org.hamcrest.MatcherAssert.assertThat(MatcherAssert.java:20)
	at org.junit.Assert.assertThat(Assert.java:956)
	at com.nekoscape.java.sample.TimezoneConversionTest.convertWithOtherTimezone_test_for_beforeJava7Method(TimezoneConversionTest.java:62)
(réduction)

Process finished with exit code -1

Deux tests ont échoué. Les deux se produisent lorsque vous spécifiez Amérique / Montréal, qui n'est pas un fuseau horaire local. Que ce passe-t-il?

L'essentiel est que cette logique présente désormais des problèmes lorsque le fuseau horaire local est l'heure d'été (heure d'été). 2016-10-02 02:00 spécifié comme la date et l'heure est la date et l'heure de début de l'heure d'été Australie / Sydney. Par conséquent, lorsqu'il est conservé comme type de date à partir d'une chaîne de caractères, cela signifie déjà 2016-10-02 03:00. En conséquence, il y a une heure d'erreur de conversion.

Comme mentionné au début, c'est un bug. Je ne l'ai pas résolu. Veuillez ne pas copier même si vous faites une erreur. La source est placée ci-dessous afin que vous puissiez l'essayer. Code source: timezone-conversion