Przypadek pierwszy:

new Date(Date.parse("Jul 8, 2005"));

Wynik:

Pt 08 lipca 2005 00:00:00 GMT-0700 (PST)

Przypadek drugi:

new Date(Date.parse("2005-07-08"));

Wynik:

Czw lip 07 2005 17:00:00 GMT-0700 (PST)

Dlaczego druga analiza jest nieprawidłowa?

Do czasu pojawienia się specyfikacji piątej edycji Date.parsemetoda była całkowicie zależna od implementacji (co new Date(string)jest równoważne z Date.parse(string)wyjątkiem tego, że ta ostatnia zwraca liczbę zamiast a Date). W specyfikacji piątej edycji dodano wymóg obsługi uproszczonej (i nieco niepoprawnej) normy ISO-8601 (zobacz także: Jakie są prawidłowe ciągi daty i godziny w JavaScript? ). Ale poza tym, nie było żadnego wymogu co Date.parse/ new Date(string)należy przyjąć inny niż musieli zaakceptować cokolwiek Date#toStringwyjściowy (nie mówiąc, co to było).

Począwszy od ECMAScript 2017 (wydanie 8), implementacje były wymagane do parsowania ich danych wyjściowych Date#toStringi Date#toUTCString, ale format tych ciągów nie został określony.

Od ECMAScript 2019 (wydanie 9) format Date#toStringi Date#toUTCStringzostały określone jako (odpowiednio):

1. ddd MMM DD RRRR GG: mm: ss ZZ [(nazwa strefy czasowej)]
   np. wt. 10 lipca 2018 18:39:58 GMT + 0530 (IST)
2. ddd, DD MMM RRRR GG: mm: ss Z
   np. Wt 10 lipca 2018 13:09:58 GMT

udostępnienie 2 dodatkowych formatów, które Date.parsepowinny być analizowane niezawodnie w nowych implementacjach (zauważając, że obsługa nie jest wszechobecna i implementacje niezgodne będą przez pewien czas używane).

Zalecałbym, aby ciągi daty były analizowane ręcznie, a konstruktor daty był używany z argumentami roku, miesiąca i dnia, aby uniknąć dwuznaczności:

// parse a date in yyyy-mm-dd format
function parseDate(input) {

  let parts = input.split('-');

  // new Date(year, month [, day [, hours[, minutes[, seconds[, ms]]]]])
  return new Date(parts[0], parts[1]-1, parts[2]); // Note: months are 0-based
}

Podczas ostatnich doświadczeń, pisząc tłumacza JS, dużo zmagałem się z wewnętrznym funkcjonowaniem dat ECMA / JS. Więc myślę, że wrzucę tutaj moje 2 centy. Mamy nadzieję, że udostępnienie tych informacji pomoże innym w razie jakichkolwiek pytań dotyczących różnic między przeglądarkami w zakresie sposobu obchodzenia się z datami.

Strona wejściowa

Wszystkie implementacje przechowują swoje wartości daty wewnętrznie jako liczby 64-bitowe, które reprezentują liczbę milisekund (ms) od 1970-01-01 UTC (GMT to to samo, co UTC). Ta data to epoka ECMAScript, która jest również używana przez inne języki, takie jak systemy Java i POSIX, takie jak UNIX. Daty występujące po epoce są liczbami dodatnimi, a wcześniejsze daty są ujemne.

Poniższy kod jest interpretowany jako ta sama data we wszystkich bieżących przeglądarkach, ale z przesunięciem lokalnej strefy czasowej:

Date.parse('1/1/1970'); // 1 January, 1970

W mojej strefie czasowej (EST, która wynosi -05: 00), wynik to 18000000, ponieważ tyle ms jest w ciągu 5 godzin (to tylko 4 godziny w miesiącach letnich). Wartość będzie inna w różnych strefach czasowych. To zachowanie jest określone w ECMA-262, więc wszystkie przeglądarki robią to w ten sam sposób.

Chociaż istnieją pewne różnice w formatach ciągów wejściowych, które główne przeglądarki będą analizować jako daty, zasadniczo interpretują je tak samo, jeśli chodzi o strefy czasowe i czas letni, nawet jeśli parsowanie jest w dużej mierze zależne od implementacji.

Jednak format ISO 8601 jest inny. Jest to jeden z dwóch formatów opisanych w ECMAScript 2015 (ed. 6), który musi zostać przeanalizowany w ten sam sposób przez wszystkie implementacje (drugi to format określony dla Date.prototype.toString ).

Ale nawet w przypadku ciągów formatu ISO 8601 niektóre implementacje źle to rozumieją. Oto wynik porównania przeglądarki Chrome i Firefox, gdy ta odpowiedź została pierwotnie napisana dla okresu 1/1/1970 (epoki) na moim komputerze przy użyciu ciągów formatu ISO 8601, które powinny zostać sparsowane do dokładnie tej samej wartości we wszystkich implementacjach:

Date.parse('1970-01-01T00:00:00Z');       // Chrome: 0         FF: 0
Date.parse('1970-01-01T00:00:00-0500');   // Chrome: 18000000  FF: 18000000
Date.parse('1970-01-01T00:00:00');        // Chrome: 0         FF: 18000000

• W pierwszym przypadku specyfikator „Z” wskazuje, że dane wejściowe są w czasie UTC, więc nie są przesunięte w stosunku do epoki, a wynik wynosi 0
• W drugim przypadku specyfikator „-0500” wskazuje, że dane wejściowe są w GMT-05: 00 i obie przeglądarki interpretują dane wejściowe w strefie czasowej -05: 00. Oznacza to, że wartość UTC jest przesunięta w stosunku do epoki, co oznacza dodanie 18000000 ms do wewnętrznej wartości czasu daty.
• Trzeci przypadek, w którym nie ma specyfikatora, powinien być traktowany jako lokalny dla systemu hosta. FF poprawnie traktuje dane wejściowe jako czas lokalny, podczas gdy Chrome traktuje je jako czas UTC, więc generuje różne wartości czasu. Dla mnie tworzy to 5-godzinną różnicę w przechowywanej wartości, co jest problematyczne. Inne systemy z różnymi przesunięciami uzyskają różne wyniki.

Ta różnica została naprawiona od 2020 r., Ale istnieją inne dziwactwa między przeglądarkami podczas analizowania ciągów formatu ISO 8601.

Ale robi się coraz gorzej. Dziwactwo ECMA-262 polega na tym, że format wyłącznie daty ISO (RRRR-MM-DD) musi być analizowany jako UTC, podczas gdy ISO 8601 wymaga, aby był analizowany jako lokalny. Oto dane wyjściowe z FF z długim i krótkim formatem daty ISO bez specyfikatora strefy czasowej.

Date.parse('1970-01-01T00:00:00');       // 18000000
Date.parse('1970-01-01');                // 0

Tak więc pierwszy jest analizowany jako lokalny, ponieważ jest to data i godzina ISO 8601 bez strefy czasowej, a drugi jest analizowany jako UTC, ponieważ jest to tylko data ISO 8601.

Tak więc, aby bezpośrednio odpowiedzieć na pierwotne pytanie, "YYYY-MM-DD"ECMA-262 musi być interpretowana jako UTC, podczas gdy drugie jest interpretowane jako lokalne. Dlatego:

To nie daje równoważnych wyników:

console.log(new Date(Date.parse("Jul 8, 2005")).toString()); // Local
console.log(new Date(Date.parse("2005-07-08")).toString());  // UTC

To robi:

console.log(new Date(Date.parse("Jul 8, 2005")).toString());
console.log(new Date(Date.parse("2005-07-08T00:00:00")).toString());

Najważniejsze jest to, aby parsować ciągi dat. TYLKO ciąg ISO 8601, który można bezpiecznie analizować w różnych przeglądarkach, to długi formularz z przesunięciem (± GG: mm lub „Z”). Jeśli to zrobisz, możesz bezpiecznie przechodzić między godzinami lokalnymi i UTC.

Działa to w różnych przeglądarkach (po IE9):

console.log(new Date(Date.parse("2005-07-08T00:00:00Z")).toString());

Większość obecnych przeglądarek równo traktuje inne formaty wejściowe, w tym często używane „1/1/1970” (M / D / RRRR) i „1/1/1970 00:00:00 AM” (M / D / RRRR hh : mm: ss ap) formaty. Wszystkie poniższe formaty (oprócz ostatniego) są traktowane jako dane czasu lokalnego we wszystkich przeglądarkach. Wyjście tego kodu jest takie samo we wszystkich przeglądarkach w mojej strefie czasowej. Ostatni jest traktowany jako -05: 00 niezależnie od strefy czasowej hosta, ponieważ przesunięcie jest ustawione na znaczniku czasu:

console.log(Date.parse("1/1/1970"));
console.log(Date.parse("1/1/1970 12:00:00 AM"));
console.log(Date.parse("Thu Jan 01 1970"));
console.log(Date.parse("Thu Jan 01 1970 00:00:00"));
console.log(Date.parse("Thu Jan 01 1970 00:00:00 GMT-0500"));

Ponieważ jednak parsowanie nawet formatów określonych w ECMA-262 nie jest spójne, zaleca się, aby nigdy nie polegać na wbudowanym analizatorze składni i zawsze ręcznie analizować ciągi, na przykład za pomocą biblioteki i przekazać format do analizatora składni.

Np. W momencie.js możesz napisać:

let m = moment('1/1/1970', 'M/D/YYYY'); 

Strona wyjściowa

Po stronie wyjściowej wszystkie przeglądarki tłumaczą strefy czasowe w ten sam sposób, ale inaczej obsługują formaty ciągów. Oto toStringfunkcje i dane wyjściowe. Zwróć uwagę na wyjście funkcji toUTCStringi toISOString5:00 AM na moim komputerze. Ponadto nazwa strefy czasowej może być skrótem i może być różna w różnych implementacjach.

Konwertuje czas UTC na czas lokalny przed wydrukowaniem

 - toString
 - toDateString
 - toTimeString
 - toLocaleString
 - toLocaleDateString
 - toLocaleTimeString

Drukuje bezpośrednio zapisany czas UTC

 - toUTCString
 - toISOString 

W Chrome

toString            Thu Jan 01 1970 00:00:00 GMT-05:00 (Eastern Standard Time)
toDateString        Thu Jan 01 1970
toTimeString        00:00:00 GMT-05:00 (Eastern Standard Time)
toLocaleString      1/1/1970 12:00:00 AM
toLocaleDateString  1/1/1970
toLocaleTimeString  00:00:00 AM

toUTCString         Thu, 01 Jan 1970 05:00:00 GMT
toISOString         1970-01-01T05:00:00.000Z

W przeglądarce Firefox

toString            Thu Jan 01 1970 00:00:00 GMT-05:00 (Eastern Standard Time)
toDateString        Thu Jan 01 1970
toTimeString        00:00:00 GMT-0500 (Eastern Standard Time)
toLocaleString      Thursday, January 01, 1970 12:00:00 AM
toLocaleDateString  Thursday, January 01, 1970
toLocaleTimeString  12:00:00 AM

toUTCString         Thu, 01 Jan 1970 05:00:00 GMT
toISOString         1970-01-01T05:00:00.000Z

Zwykle nie używam formatu ISO do wprowadzania tekstu. Używanie tego formatu jest dla mnie jedyne, kiedy daty muszą być sortowane jako ciągi. Format ISO można sortować w obecnym stanie, podczas gdy inne nie. Jeśli musisz mieć zgodność z różnymi przeglądarkami, określ strefę czasową lub użyj zgodnego formatu ciągu.

Kod new Date('12/4/2013').toString()przechodzi następującą wewnętrzną pseudo-transformację:

  "12/4/2013" -> toUCT -> [storage] -> toLocal -> print "12/4/2013"

Mam nadzieję, że ta odpowiedź była pomocna.

W szaleństwie jest jakaś metoda. Zasadniczo, jeśli przeglądarka może interpretować datę jako ISO-8601, zrobi to. „2005-07-08” wpada do tego obozu i dlatego jest analizowany jako UTC. „8 lipca 2005 r.” Nie może, dlatego jest analizowany w czasie lokalnym.

Zobacz JavaScript i daty, co za bałagan! po więcej.

Innym rozwiązaniem jest zbudowanie tablicy asocjacyjnej z formatem daty, a następnie sformatowanie danych.

Ta metoda jest przydatna w przypadku daty sformatowanej w nietypowy sposób.

Przykład:

    mydate='01.02.12 10:20:43':
    myformat='dd/mm/yy HH:MM:ss';


    dtsplit=mydate.split(/[\/ .:]/);
    dfsplit=myformat.split(/[\/ .:]/);

    // creates assoc array for date
    df = new Array();
    for(dc=0;dc<6;dc++) {
            df[dfsplit[dc]]=dtsplit[dc];
            }

    // uses assc array for standard mysql format
    dstring[r] = '20'+df['yy']+'-'+df['mm']+'-'+df['dd'];
    dstring[r] += ' '+df['HH']+':'+df['MM']+':'+df['ss'];

Użyj moment.js, aby przeanalizować daty:

var caseOne = moment("Jul 8, 2005", "MMM D, YYYY", true).toDate();
var caseTwo = moment("2005-07-08", "YYYY-MM-DD", true).toDate();

Trzeci argument określa ścisłe analizowanie (dostępne od 2.3.0). Bez tego moment.js może również dawać nieprawidłowe wyniki.

Zgodnie z http://blog.dygraphs.com/2012/03/javascript-and-dates-what-mess.html format „rrrr / mm / dd” rozwiązuje zwykłe problemy. Mówi: „Trzymaj się„ RRRR / MM / DD ”dla ciągów daty, gdy tylko jest to możliwe. Jest to powszechnie obsługiwane i jednoznaczne. W tym formacie wszystkie czasy są lokalne.” Ustawiłem testy: http://jsfiddle.net/jlanus/ND2Qg/432/ Ten format: + pozwala uniknąć niejednoznaczności zamówień dnia i miesiąca, używając zamawiania ymd, a 4-cyfrowy rok + pozwala uniknąć problemu UTC vs. zgodność z formatem ISO za pomocą ukośników + danvk, facet z dygraphs , mówi, że ten format jest dobry we wszystkich przeglądarkach.

Chociaż CMS ma rację, że przekazywanie ciągów do metody parsowania jest ogólnie niebezpieczne, nowa specyfikacja ECMA-262 5. edycja (znana również jako ES5) w sekcji 15.9.4.2 sugeruje, że Date.parse()faktycznie powinna obsługiwać daty sformatowane w ISO. Stara specyfikacja nie zawierała takiego twierdzenia. Oczywiście stare przeglądarki i niektóre obecne przeglądarki nadal nie zapewniają tej funkcji ES5.

Twój drugi przykład nie jest zły. Jest to określona data w UTC, jak sugeruje Date.prototype.toISOString(), ale jest reprezentowana w lokalnej strefie czasowej.

Ta lekka biblioteka analizująca datę powinna rozwiązać wszystkie podobne problemy. Podoba mi się biblioteka, ponieważ jest dość łatwa do rozszerzenia. Możliwe jest również i18n to (niezbyt proste, ale nie tak trudne).

Przykład parsowania:

var caseOne = Date.parseDate("Jul 8, 2005", "M d, Y");
var caseTwo = Date.parseDate("2005-07-08", "Y-m-d");

I formatowanie z powrotem do łańcucha (zauważysz, że oba przypadki dają dokładnie ten sam wynik):

console.log( caseOne.dateFormat("M d, Y") );
console.log( caseTwo.dateFormat("M d, Y") );
console.log( caseOne.dateFormat("Y-m-d") );
console.log( caseTwo.dateFormat("Y-m-d") );

Oto krótki, elastyczny fragment kodu służący do konwersji ciągu datetime w sposób bezpieczny dla różnych przeglądarek, który jest szczegółowo opisany przez @ drankin2112.

var inputTimestamp = "2014-04-29 13:00:15"; //example

var partsTimestamp = inputTimestamp.split(/[ \/:-]/g);
if(partsTimestamp.length < 6) {
    partsTimestamp = partsTimestamp.concat(['00', '00', '00'].slice(0, 6 - partsTimestamp.length));
}
//if your string-format is something like '7/02/2014'...
//use: var tstring = partsTimestamp.slice(0, 3).reverse().join('-');
var tstring = partsTimestamp.slice(0, 3).join('-');
tstring += 'T' + partsTimestamp.slice(3).join(':') + 'Z'; //configure as needed
var timestamp = Date.parse(tstring);

Twoja przeglądarka powinna zapewniać ten sam wynik znacznika czasu, co Date.parse:

(new Date(tstring)).getTime()

Oba są poprawne, ale są interpretowane jako daty z dwiema różnymi strefami czasowymi. Więc porównałeś jabłka i pomarańcze:

// local dates
new Date("Jul 8, 2005").toISOString()            // "2005-07-08T07:00:00.000Z"
new Date("2005-07-08T00:00-07:00").toISOString() // "2005-07-08T07:00:00.000Z"
// UTC dates
new Date("Jul 8, 2005 UTC").toISOString()        // "2005-07-08T00:00:00.000Z"
new Date("2005-07-08").toISOString()             // "2005-07-08T00:00:00.000Z"

Usunąłem Date.parse()wywołanie, ponieważ jest ono używane automatycznie w argumencie ciągu. Porównałem również daty w formacie ISO8601 , abyś mógł wizualnie porównać daty między datami lokalnymi a datami UTC. Czasy różnią się od siebie o 7 godzin, co jest różnicą w strefie czasowej i dlatego twoje testy wykazały dwie różne daty.

Innym sposobem utworzenia tych samych dat lokalnych / UTC byłoby:

new Date(2005, 7-1, 8)           // "2005-07-08T07:00:00.000Z"
new Date(Date.UTC(2005, 7-1, 8)) // "2005-07-08T00:00:00.000Z"

Ale nadal zdecydowanie polecam Moment.js, który jest tak prosty, ale potężny :

// parse string
moment("2005-07-08").format()       // "2005-07-08T00:00:00+02:00"
moment.utc("2005-07-08").format()   // "2005-07-08T00:00:00Z"
// year, month, day, etc.
moment([2005, 7-1, 8]).format()     // "2005-07-08T00:00:00+02:00"
moment.utc([2005, 7-1, 8]).format() // "2005-07-08T00:00:00Z"

Odpowiedź przyjmowane od CMS jest poprawne, ja po prostu dodać kilka funkcji:

• przycinaj i oczyszczaj przestrzenie wejściowe
• parsuj ukośniki, myślniki, dwukropki i spacje
• ma domyślny dzień i godzinę

// parse a date time that can contains spaces, dashes, slashes, colons
function parseDate(input) {
    // trimes and remove multiple spaces and split by expected characters
    var parts = input.trim().replace(/ +(?= )/g,'').split(/[\s-\/:]/)
    // new Date(year, month [, day [, hours[, minutes[, seconds[, ms]]]]])
    return new Date(parts[0], parts[1]-1, parts[2] || 1, parts[3] || 0, parts[4] || 0, parts[5] || 0); // Note: months are 0-based
}