Javascript - De ce dă rezultate incorecte Stack Overflow

Primul caz:

Ieșire:

Vin 08 Iul 2005 00:00:00 GMT-0700 (PST)

toate browserele

Al doilea caz:

Ieșire:

Joi 07 iulie 2005 17:00:00 GMT-0700 (PST)

De ce este a doua analiză incorectă?

11 Răspunsuri 11

Până la apariția specificației ediției a 5-a, metoda Date.parse a fost complet dependentă de implementare (data nouă (șir) este echivalentă cu Date.parse (șir), cu excepția faptului că acesta din urmă returnează un număr mai degrabă decât o dată). În specificația ediției a 5-a, cerința a fost adăugată pentru a accepta un ISO-8601 simplificat (și ușor incorect) (a se vedea, de asemenea, Ce sunt șirurile de date și ora valide în JavaScript?). Dar, în afară de asta, nu a existat nicio cerință pentru ce Date.parse/new Date (șir) ar trebui să accepte, în afară de faptul că trebuiau să accepte orice ieșire Date # toString (fără să spună ce este asta).

Începând cu ECMAScript 2017 (ediția 8), implementările au fost necesare pentru a analiza rezultatul pentru Date # toString și Date # toUTCString, dar formatul acestor șiruri nu a fost specificat.

Începând cu ECMAScript 2019 (ediția 9), formatul pentru Date # toString și Date # toUTCString, a fost specificat ca (respectiv):

  1. ddd MMM DD AAAA HH: mm: ss ZZ [(numele fusului orar)]
    de exemplu. Mar 10 iul 2018 18:39:58 GMT + 0530 (IST)
  2. ddd, DD MMM AAAA HH: mm: ss Z
    de exemplu. Marți 10 iul 2018 13:09:58 GMT

furnizarea a încă 2 formate pe care Date.parse ar trebui să le analizeze în mod fiabil în noile implementări (menționând că suportul nu este omniprezent și implementările neconforme vor rămâne utilizate pentru o perioadă de timp).

Aș recomanda ca șirurile de date să fie analizate manual și constructorul de date să fie folosit cu argumente de an, lună și zi pentru a evita ambiguitatea:

În timpul experienței recente de scriere a unui interpret JS, m-am luptat mult cu funcționarea interioară a datelor ECMA/JS. Deci, cred că îmi voi arunca cei 2 cenți aici. Sperăm că partajarea acestor lucruri îi va ajuta pe ceilalți cu orice întrebări cu privire la diferențele dintre browsere în modul în care gestionează datele.

Toate implementările își stochează valorile datei intern ca numere pe 64 de biți care reprezintă numărul de milisecunde (ms) din 1970-01-01 UTC (GMT este același lucru cu UTC). Această dată este epoca ECMAScript care este utilizată și de alte limbaje, cum ar fi sistemele Java și POSIX, cum ar fi UNIX. Datele care apar după epocă sunt numere pozitive, iar datele anterioare sunt negative.

Următorul cod este interpretat ca aceeași dată în toate browserele curente, dar cu compensarea fusului orar local:

În fusul meu orar (EST, care este -05: 00), rezultatul este 18000000 pentru că atât sunt mulți ms în 5 ore (sunt doar 4 ore în lunile de vară). Valoarea va fi diferită în diferite fusuri orare. Acest comportament este specificat în ECMA-262, deci toate browserele o fac în același mod.

Deși există o oarecare variație în formatele șirurilor de intrare pe care browserele majore le vor analiza ca date, ele le interpretează în esență la fel în ceea ce privește fusurile orare și ora de vară, deși analiza depinde în mare măsură de implementare.