Pourquoi la soustraction de ces deux temps (en 1927) donne-t-elle un résultat étrange ?

Question

Si j'exécute le programme suivant, qui analyse deux chaînes de dates faisant référence à des moments séparés d'une seconde et les compare :

public static void main(String[] args) throws ParseException {
    SimpleDateFormat sf = new SimpleDateFormat("yyyy-MM-dd HH:mm:ss");  
    String str3 = "1927-12-31 23:54:07";  
    String str4 = "1927-12-31 23:54:08";  
    Date sDt3 = sf.parse(str3);  
    Date sDt4 = sf.parse(str4);  
    long ld3 = sDt3.getTime() /1000;  
    long ld4 = sDt4.getTime() /1000;
    System.out.println(ld4-ld3);
}

Le résultat est le suivant :

353

Pourquoi la ld4-ld3 no 1 (comme je m'y attendais compte tenu de la différence d'une seconde entre les temps), mais 353 ?

Si je change les dates en heures 1 seconde plus tard :

String str3 = "1927-12-31 23:54:08";  
String str4 = "1927-12-31 23:54:09";  

Dans ce cas ld4-ld3 sera 1 .

---

Version Java :

java version "1.6.0_22"
Java(TM) SE Runtime Environment (build 1.6.0_22-b04)
Dynamic Code Evolution Client VM (build 0.2-b02-internal, 19.0-b04-internal, mixed mode)

Timezone(`TimeZone.getDefault()`):

sun.util.calendar.ZoneInfo[id="Asia/Shanghai",
offset=28800000,dstSavings=0,
useDaylight=false,
transitions=19,
lastRule=null]

Locale(Locale.getDefault()): zh_CN

Answer 1

Il y a un changement de fuseau horaire le 31 décembre à Shanghai.

Voir cette page pour plus de détails sur l'année 1927 à Shanghai. En fait, à minuit, à la fin de l'année 1927, les horloges ont reculé de 5 minutes et 52 secondes. Donc "1927-12-31 23:54:08" s'est en fait produit deux fois, et il semble que Java l'interprète comme la balise plus tard instant possible pour cette date/heure locale - d'où la différence.

Un épisode de plus dans le monde souvent étrange et merveilleux des fuseaux horaires.

Si elle est reconstruite avec la version 2013a de TZDB La question initiale n'aurait plus tout à fait le même comportement. En 2013a, le résultat serait de 358 secondes, avec un temps de transition de 23:54:03 au lieu de 23:54:08.

Je ne l'ai remarqué que parce que je recueille des questions de ce type dans Noda Time, sous la forme de tests unitaires ... Le test a été modifié, mais cela montre bien que même les données historiques ne sont pas sûres.

Dans TZDB 2014f l'heure du changement a été déplacée à 1900-12-31, et il ne s'agit plus que d'un changement de 343 secondes (donc le temps entre le t y t+1 est de 344 secondes, si vous voyez ce que je veux dire).

---

Pour répondre à une question concernant une transition à 1900... il semble que l'implémentation du fuseau horaire de Java traite todos Les fuseaux horaires sont considérés comme étant simplement dans leur heure standard pour tout instant avant le début de 1900 UTC :

import java.util.TimeZone;

public class Test {
    public static void main(String[] args) throws Exception {
        long startOf1900Utc = -2208988800000L;
        for (String id : TimeZone.getAvailableIDs()) {
            TimeZone zone = TimeZone.getTimeZone(id);
            if (zone.getRawOffset() != zone.getOffset(startOf1900Utc - 1)) {
                System.out.println(id);
            }
        }
    }
}

Le code ci-dessus ne produit aucun résultat sur ma machine Windows. Ainsi, tout fuseau horaire ayant un décalage autre que son décalage standard au début de l'année 1900 sera considéré comme une transition. La base de données TZDB elle-même contient des données antérieures à cette date et ne repose pas sur l'idée d'une heure standard "fixe" (ce qui est le cas de la base de données TZDB). getRawOffset (ce qui semble être un concept valide), de sorte que les autres bibliothèques n'ont pas besoin d'introduire cette transition artificielle.

Answer 2

Vous avez rencontré un discontinuité du temps local :

Lorsque l'heure locale s'apprêtait à passer au dimanche 1er janvier 1928, les horloges ont été mises à l'heure de 00:00:00, 00:00:00, les horloges ont été reculées de 0:05:52 heures jusqu'au samedi 31. décembre 1927, 23:54:08 heure locale au lieu de

Cette situation n'est pas particulièrement étrange et s'est produite un peu partout à un moment ou à un autre, lorsque les fuseaux horaires ont été modifiés ou changés à la suite d'actions politiques ou administratives.

Answer 3

La morale de cette étrangeté est la suivante :

• Utilisez les dates et heures en UTC dans la mesure du possible.
• Si vous ne pouvez pas afficher une date ou une heure en UTC, indiquez toujours le fuseau horaire.
• Si vous ne pouvez pas exiger une date/heure d'entrée en UTC, exigez un fuseau horaire explicitement indiqué.

Answer 4

Lorsque vous augmentez le temps, vous devez le convertir en UTC, puis l'ajouter ou le soustraire. N'utilisez l'heure locale que pour l'affichage.

Vous pourrez ainsi traverser les périodes où les heures ou les minutes se répètent deux fois.

Si vous avez converti en UTC, ajoutez chaque seconde et convertissez en heure locale pour l'affichage. Vous passeriez ainsi à 11:54:08 p.m. LMT - 11:59:59 p.m. LMT et ensuite 11:54:08 p.m. CST - 11:59:59 p.m. CST.

Answer 5

J'ai exécuté votre code, le résultat est le suivant :

-1325466353
-1325466352
1

Et.. :

-1325466352
-1325466351
1

sur :

$ java -version
java version "1.6.0_20"
OpenJDK Runtime Environment (IcedTea6 1.9.7) (fedora-52.1.9.7.fc14-i386)
OpenJDK Client VM (build 19.0-b09, mixed mode)