Navigateurs, fuseaux horaires, erreur Chrome 67
J'ai mis à jour Chrome à la version 67. Et je reçois une erreur avec la date
==============
Microsoft Edge 42.17134.1.0
new Date("1900-01-01T00:00:00").getTimezoneOffset()
-180
new Date("2018-05-30T00:00:00").getTimezoneOffset()
-180
Microsoft Internet Explorer 11.48.17134.0
new Date("1900-01-01T00:00:00").getTimezoneOffset()
-180
new Date("2018-05-30T00:00:00").getTimezoneOffset()
-180
Mozilla Firefox 60.0.1
new Date("1900-01-01T00:00:00").getTimezoneOffset()
-180
new Date("2018-05-30T00:00:00").getTimezoneOffset()
-180
Chrome 67.0.3396.62
new Date("1900-01-01T00:00:00").getTimezoneOffset()
-150
new Date("2018-05-30T00:00:00").getTimezoneOffset()
-180
=======================
-150 en chrome 67 ...
Un autre exemple (Chrome 67):
new Date("1900-01-01T00:00:00");
Mon Jan 01 1900 00:00:00 GMT+0230 (Moscow Standard Time)
=======================
Avec Chrome 67, les fuseaux horaires étaient incorrects (+0230, c'était: +0300)
S'il vous plaît dites-moi?
Que puis-je faire ?
La situation est très importante! Tout le code que je dois réécrire ...
=======================
Je vais supposer que vous êtes dans le fuseau horaire Europe/Moscou - cela semble probable compte tenu de la sortie que vous avez fournie.
En 1900, le fuseau horaire Europe/Moscou avait un décalage de +02: 30: 17, selon la base de données de fuseaux horaires IANA . Vraisemblablement, Chrome arrondit à 02:30 pour éviter les décalages inférieurs à une minute, mais il renvoie des données appropriées à ma connaissance. La compensation en Russie est d'abord devenue un nombre entier d'heures en 1919, du moins selon la base de données IANA.
Vous devriez peut-être vous demander pourquoi les autres navigateurs ne le font pas - mais plus probablement, vous devriez modifier votre code pour ne pas demander d'informations de fuseau horaire avant 1970. La base de données IANA vise à fournir des données précises provenant de l'époque Unix. à partir de rien de plus tôt est vraiment "meilleur effort". À partir du fichier theory :
Les transitions d’horloge antérieures à 1970 sont enregistrées pour chacun de ces emplacements, car la plupart des systèmes prennent en charge les horodatages antérieurs à 1970 et pourraient se comporter de manière erronée si les entrées de données étaient omises pour les transitions antérieures à 1970. Cependant, la base de données n'est pas conçue pour et ne suffit pas pour les applications nécessitant un traitement précis de tous les temps passés, car il faudrait beaucoup trop d'efforts et de conjectures pour enregistrer tous les détails du chronométrage civil d'avant 1970. Bien que certaines informations hors du champ de la base de données soient collectées dans une zone de fond de fichier distribuée avec la base de données proprement dite, ce fichier est moins fiable et ne respecte pas nécessairement les instructions de la base de données.
Pour ce qui est de la raison pour laquelle vous voyez cela avec Chrome 67 si vous ne le voyiez pas avec les versions précédentes de Chrome, je me demande si Chrome vient juste de commencer à intégrer les données de fuseau horaire IANA au lieu d'utiliser les données du système d'exploitation.
J'ai eu des problèmes similaires lors de l'utilisation de la new Date(".."); constructeur. (également depuis que la version de Chrome a changé)
Une note de MDN Date Référence :
Remarque: l'analyse des chaînes de date avec le constructeur Date (et Date.parse, elles sont équivalentes) est fortement déconseillée en raison des différences et des incohérences du navigateur. La prise en charge des chaînes de format RFC 2822 est par convention uniquement. La prise en charge des formats ISO 8601 diffère par le fait que les chaînes datées uniquement (par exemple, "1970-01-01") sont traitées comme des heures UTC et non locales.
Peut-être est-il possible dans votre code d’utiliser un autre construcuteur Date tel que:
new Date(Date.UTC(96, 1, 2, 3, 4, 5));