2015-11-29 15 views
8

Ho appena scoperto che se uso new Date('2015-1-1'), l'ora non ha effetto fuso orario, ma Se utilizzo new Date('2015-01-01') l'ora ha l'effetto fuso orario in Node.js.Date ('2015-1-1') uscite diverse da Date (2015-01-01)

ho uscita 4 Date():

console.log(new Date('2015-1-1')); 
    console.log(new Date('2015-01-1')); 
    console.log(new Date('2015-1-01')); 
    console.log(new Date('2015-01-01')); 

l'uscita è

Thu Jan 01 2015 00:00:00 GMT+0800 (CST) 
Thu Jan 01 2015 00:00:00 GMT+0800 (CST) 
Thu Jan 01 2015 00:00:00 GMT+0800 (CST) 
Thu Jan 01 2015 08:00:00 GMT+0800 (CST) 

si può vedere l'ultima volta che è 08:00:00 perché sono in otto fuso orario.

Penso che l'uscita dipenda dalla cifra del mese o dal numero della data. Quando è 10, 11 o 12 l'output è sempre 08:00:00

Mi chiedo perché e se c'è un modo migliore per gestirlo tranne controllare manualmente il bit del mese e il numero della data?

+1

ottengo lo stesso output quando eseguo i tuoi esempi su Chrome console Javascript in modo sembra essere un bug/funzionalità V8. – HBP

+0

In Firefox ho ricevuto una data non valida per tutti tranne l'ultima riga. Inoltre, ho trovato questo da MDN: [Differenze nel presunto fuso orario] (https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Date/parse#Differences_in_assumed_time_zone) – Kobi

+5

Eppure un altro problema con le stringhe di data di analisi. Il ** solo ** modo affidabile per analizzare una stringa di data è farlo manualmente (anche se una libreria può essere d'aiuto). Le prime 3 stringhe non sono esattamente stringhe ISO 8601, quindi possono essere analizzate, tuttavia l'implementazione richiede. L'ultimo è un formato ISO 8601. Per ECMAScript 2015 viene analizzato come "locale" nel sistema host. Sotto ES5 deve essere analizzato come UTC, e prima di ciò (cioè ECMAScript ed 3 e precedenti) qualsiasi cosa, incluso NaN. – RobG

risposta

1

Fino al ECMA-262 ed 3, l'analisi delle stringhe di date era interamente dipendente dall'implementazione. Con ES5, le stringhe di formato ISO 8601 senza fuso orario dovevano essere analizzate come UTC, tuttavia l'analisi di qualsiasi altro tipo di stringa di data dipende ancora dall'implementazione.

Con ECMAScript 2015, tali stringhe senza fuso orario devono essere analizzate come locali (ovvero con un offset basato sulle impostazioni di sistema).

Quindi sembrerebbe che l'implementazione Node.js non riconosca le prime 3 stringhe come ISO 8601 e quindi le analizzi secondo qualche altra logica interna che le tratta come UTC.

L'ultima stringa è considerata conforme a ISO 8601 e pertanto viene analizzata come locale.

Se si desidera analizzare tutte queste stringhe come locale, è possibile utilizzare una semplice funzione come:

/* @param {string} s - date string in format yyyy-[m]m-[d]d 
 
** @returns {Date} - a Date object for the specified date in a 
 
** timezone based on system settings. 
 
** Assumes that the string is a valid date. 
 
*/ 
 
function parseISOLocal (s) { 
 
    var b = s.split(/\D/); 
 
    return new Date(b[0], b[1]-1, b[2]); 
 
} 
 

 
document.write(parseISOLocal('2015-1-1'))

+0

Con questa funzione ho ottenuto 'Gio Jan 01 2015 00:00:00 GMT + 0800 (CST)', nessun offset fuso orario, ma la data predefinita 'Date (' 2015-01-01 ') ha l'offset del fuso orario. –

+0

@ BrickYang: il primo ha uno scostamento del fuso orario (+08: 00). – RobG

0

probabilmente di un bug, il meglio che si può fare è quello di utilizzare una libreria come Moment che sembra libero da questo:

moment('2015-1-1').toString() 
moment('2015-1-01').toString() 
moment('2015-01-1').toString() 
moment('2015-01-01').toString() 

stampe:

"Thu Jan 01 2015 00:00:00 GMT+0100" 
"Thu Jan 01 2015 00:00:00 GMT+0100" 
"Thu Jan 01 2015 00:00:00 GMT+0100" 
"Thu Jan 01 2015 00:00:00 GMT+0100" 
+0

[Bug in effetti] (https://code.google.com/p/chromium/issues/detail?id=543320). –

+0

Non proprio, succede solo che moment.js, per impostazione predefinita, ha un certo comportamento.Non hai spiegato perché l'OP ottiene il risultato che ottengono. – RobG

+0

Non ho idea del perché, la mia risposta si riferiva al "modo migliore per gestire questo". Dal momento che Moment sembra coerente su questo e fornisce anche molte funzioni interessanti sembra un buon modo per gestire questo. – Enrichman