Sono confuso ma in javascript:in JavaScript: Perché new Date ('2012/01/15') - new Date ('2012-01-15') == 21.600.000
> new Date('2012-1-15') - new Date('2012-01-15')
21600000
Perché quella? (21 milioni seicento mille/1000/3600 == 6 ore)
il formato data yyyy-mm-dd (2012-01-15) è analizzato come una data UTC mentre yyyy-m-dd (2012/01/15) viene analizzato come data locale. Questo è mostrato se si utilizza .toString su ciascuno.
> (new Date('2012-01-15')).toString()
"Sat Jan 14 2012 16:00:00 GMT-0800 (Pacific Standard Time)"
> (new Date('2012-1-15')).toString()
"Sun Jan 15 2012 00:00:00 GMT-0800 (Pacific Standard Time)"
Nota che sono in California, da qui l'ora solare del Pacifico. Se ti trovi in un fuso orario diverso, otterrai risultati diversi.
Quando JavaScript analizza le date, prova prima i formati utilizzati in più aree (come l'UTC) prima di provare i formati di data localizzati. L'ultima parte del formato di data UTC è una differenza di fuso orario rispetto a GMT che si presume essere 0 quando manca (come in questo esempio). Per ottenere la stessa data è necessario il timestamp UTC completo: 2012-01-15T00: 00: 00-08: 00.
sarebbe interessante sapere/perché/questo accade. – Hamish
@Hamish Ho aggiunto un po 'di spiegazione, fammi sapere se dovrei andare più in profondità. –
Molto strano, da allora, come dovrebbe essere analizzato il 2012-10-15? non può essere sia utc che locale. –
a= new Date('2012-1-16')
b= new Date('2012-01-16')
alert(a);
alert(b);
Per il primo caso, la funzione costruttore imposta l'ora 00:00 nel fuso orario. Ma nel secondo caso, inizializza il tempo relativo a GMT +00.00
Il risultato di new Date('2012-1-15') dipende dall'implementazione (ECMAScript standard, clausola 15.9.4.2).
Stampa qui 14400000, ovvero 4 ore. Sono a GMT-4. Questo è probabilmente correlato :) – BalusC
Fallisce per me - il 2012-1-15 restituisce una data non valida invece di un oggetto data (FF 9.0.1), causando il tutto per restituire NaN. –
Ottengo 18000000, 5 ore, e io sono GMT-5 ... Sono con @BalusC su questo. –