Pourquoi utilise JavaScript pour planifier Q1 année 22034 peu fiables dans Safari?

Question

Il y a quelque chose de louche dans le calcul des dates futures de loin lorsque vous avez terminé sur le côté du navigateur (Safari 5.0.1), en passant des chaînes dans la Date () constructeur:

Je réduit à la transition Février-Mars de l'année 22034:

d = new Date('1 Mar 22034')
Tue Feb 28 22034 00:00:00 GMT+0000 (GMT)

Feeding une date ultérieure , le constructeur renvoie toujours un objet Date hors par un jour!

Qu'en est-il des dates antérieures? Le dernier jour en Février semble bon:

d=new Date('28 Feb 22034')
Tue Feb 28 22034 00:00:00 GMT+0000 (GMT)

Mon instinct me dit-sentiment qui ressemble à bug lié d'un bissextiles . Mais quel est le modèle en jeu ici, ce qui pourrait être l'explication du bug?

---

Edit:

Et si nous demandons 29 Février?

d=new Date('29 Feb 22034')
Wed Mar 01 22034 00:00:00 GMT+0000 (GMT)

Que retourne la dernière de février + 1 jour (son comportement standard).

Answer 1

Il est parce que le format de date que vous donnez new Date() est non standard. Le fait que vous obtenez quoi que ce soit parce que Safari vous fait une faveur. (Voir la section 15.9.1.15 de la spécification pour les formats valides; essentiellement un ISO-8601 simplifié. Et avoir any standard pour l'analyse syntaxique des chaînes de date / heure est relativement nouvelle [5ème édition].)

Si vous utilisez un constructeur standard, par exemple, new Date (22034, 2, 1) (mois commencent à zéro, soit 1 Mars, 22034), il fonctionne très bien. Vous pouvez le tester comme celui-ci ( copie en direct ):

display("With non-standard string: " + new Date("1 Mar 22034"));
display("Using standard constructor: " + new Date(22034, 2, 1));

Ce qui me l'aide de Safari pour Windows dans les résultats:

  

Avec chaîne non standard: Tue Feb 28 22034 00:00:00 GMT + 0000 (heure normale GMT)   
Utilisation constructeur standard: Mer Mar 01 22034 00:00:00 GMT + 0000 (heure normale GMT)

Comme vous pouvez le voir, la première montre de ligne la date incorrecte, alors que la seconde montre de ligne correcte.

Le constructeur norme fonctionne également correctement dans Chrome, Opera et Firefox (tous sous Ubuntu), IE6, IE7 et IE8: http://jsbin.com/ogiqu

S'il était vraiment vrai que Safari ne pouvait pas gérer cette date (par opposition à ne pas analyse de la chaîne non standard, vous avez donné de manière fiable), il serait surprenant bug spécifique Safari. De section 15.9.1.1 de la spécification :

  

Le temps est mesuré en ECMAScript en millisecondes depuis le 01 Janvier, 1970 UTC. Dans le temps des valeurs secondes bissextiles   sont ignorés. On suppose qu'il ya exactement 86.400.000 millisecondes par jour. Les valeurs ECMAScript Nombre   peuvent représenter tous les nombres entiers de -9.007.199.254.740.991 à 9.007.199.254.740.991; cette gamme suffit à   mesurer les temps de précision milliseconde pour tout instant qui est à environ 285616 années, que ce soit   avant ou en arrière, du 01 Janvier, 1970 UTC.

Mais comme Safari semble le manipuler bien quand vous ne demandez pas d'aller hors-piste, apparemment le problème est dans le code d'analyse syntaxique pour les chaînes non standard.