2016-12-28 3 views
6

Ich fühle mich hier etwas vermisst.Date.getDay() gibt verschiedene Werte zurück

Die Date.getDay() -Methode soll einen Wert von 0-6 zurückgeben. 0 für Sonntag und 6 für Samstag.

Jetzt habe ich zwei Tage, sind beide ‚Sonntag‘, die 0.

new Date('1990-11-11').getDay() // returns 6 
new Date('2016-1-3').getDay() // returns 0 

Was die Diskrepanz zurückgeben sollte verursacht? Ich wage es, die Gültigkeit der .getDay() Methode in Frage zu stellen, aber ich kann nicht herausfinden, was vor sich geht.

EDIT

> new Date('1990-11-11') 
Sat Nov 10 1990 17:00:00 GMT-0700 (MST) 
> new Date('2016-01-03') 
Sat Jan 02 2016 17:00:00 GMT-0700 (MST) 
> new Date('2016-1-3') // they say this format is wrong, but it returns the right date 
Sun Jan 03 2016 00:00:00 GMT-0700 (MST) 

Ich verstehe nicht, was los ist. Der 3. Januar ist Sonntag und der 11. November 1990 ist Sonntag. Warum sagt es Samstag?

+2

Auf meinem Rechner beide 0 zurück – ppasler

+0

auf meiner Maschine zurückkehren auch 0 new Date ('1990.11.11'). GetDay() return 0 new Date ('2016.01.03') .getDay() return 0 – CommonPlane

+0

beide geben 0 in meinem Fall zurück. Überprüfen Sie diese https://jsfiddle.net/yzyqruyc/ – amulya349

Antwort

1

Sicherlich Ihre Behauptung, dass 1990-11-11 Sonntag ist wahr, aber Sie müssen verstehen, dass JavaScript Date Objekt:

  • Griffe Zeit sowie Datum
  • Ist Zeitzone bewusst
  • Ist schlecht entworfen und eher kontraintuitiv

Ihr eigene Tests verdeutlichen dies:

new Date('1990-11-11').getDay() // returns 6 
> new Date('1990-11-11') 
Sat Nov 10 1990 17:00:00 GMT-0700 (MST) 

Was passiert ist, dass constructor assumes local time or UTC depending on the syntax used:

Hinweis: Wo Datum als Konstruktor mit mehr als einem Argument aufgerufen wird, werden die specifed Argumente Ortszeit darstellen. Wenn UTC gewünscht ist, verwenden Sie ein neues Date (Date.UTC (...)) mit denselben Argumenten.

Hinweis: Parsen von Datumszeichenfolgen mit dem Date-Konstruktor (und Date.parse, sie sind gleichwertig) stark aufgrund Browser Unterschiede und Widersprüche entmutigt. Unterstützung für RFC 2822-Format Strings ist nur nach Vereinbarung. Die Unterstützung für ISO 8601-Formate unterscheidet sich in , dass nur-Datum-Strings (z. B. "1970-01-01") als UTC behandelt werden, nicht lokal.

... und Ihre Syntax macht es als UTC. Aber many others methods nehmen Ortszeit:

Die getDay() -Methode gibt den Tag der Woche für das angegebene Datum nach Ortszeit, wobei 0 Sonntag darstellt.

+0

Ich denke, diese Antwort beschreibt, was am besten läuft. Danke Alvaro. – magreenberg

+0

Das Design scheint klobig und benutzerunfreundlich, aber in der Fairness sind Daten an sich komplex. Sie wissen das nicht zu schätzen, bis Sie mit den Anwendungsfällen im Detail und an verschiedenen Standorten mit unterschiedlichen Konventionen für die Sommerzeit beginnen. Die JS-Implementierung ist logisch konsistent, trotz all ihrer scheinbaren Fremdartigkeit. Wie bei so viel Software versucht der Schlüssel, in den Kopf des Entwicklers zu gelangen. –

+1

@RobLyndon JavaScript Datumsverarbeitung ist in der Tat ziemlich umfangreich und robust, aber die API ist extrem verwirrend (und das war es, was ich meinte, wenn ich mich über das Design beschwerte). Ich meine ... Null-basierte Monate? Konstruktor mit drei verschiedenen Signaturen, die sich je nach Format der Werte und der Browserkonfiguration unterschiedlich verhalten? 'getFullYear()' hinzugefügt, um Y2K-Probleme zu beheben? –

0

getDay liefert Tagesindex (von 0 bis 6), wobei 0 Sonntag ist. https://developer.mozilla.org/en/docs/Web/JavaScript/Reference/Global_Objects/Date/getDay

Rückgabewert: eine ganze Zahl ist auf den Tag der Woche für das angegebene Datum entspricht, gemäß Ortszeit: 0 für Sonntag, 1 für Montag, 2 für Dienstag, und so weiter.

Aktualisierung: new Datumskonstruktor gibt verschiedene Zeitwerte für diese Daten zurück.

new Date('2016-1-3') ==> Sun Jan 03 2016 00:00:00 GMT+0100 (CET)

new Date('1990-11-11') ==> Sun Nov 11 1990 01:00:00 GMT+0100 (CET)

Und aus irgendeinem Grund, wird die erste als Samstag auf Ihrem Rechner interpretiert. Es tut uns nicht in der Lage mehr

Update2 zu helfen:

Verwendung von zwei Ziffern für Monat/Tag sollten die Ergebnisse standardisieren. Beispiel:

(new Date('2016-01-03')).getDay() ==> 0

getDay

+0

Es ist klar, wie 'getDay()' funktioniert, aber OP bekommt die falsche Nummer. – ppasler

+1

OP erklärte in der Frage, dass das erwartete Ergebnis für beide 0 ist, da sie beide Sonntage sind. Das bedeutet, OP weiß, was die Funktion macht. – UnholySheep

3

Die eine, die falsch ist, ist derjenige, der Sonntag zurückkehrt, und das muss sein, da das Format nicht korrekt ist. 1990-11-11 wird um Mitternacht des 11., UTC als 00:00:00 interpretiert, was am Samstag, dem 10. in Ihrer Zeitzone 17 Uhr ist.

Wenn Sie getUTCDay() verwenden, sollten Sie 0 für beide Daten erhalten.

new Date('1990-11-11').getUTCDay() // returns 0 
new Date('2016-01-03').getUTCDay() // returns 0 
+0

Ich stimme dieser Antwort voll und ganz zu. Offensichtlich ist das '2016-1-3' nicht im ISO-Format. Sie würden denken, dass ungültige Formate Fehler werfen würden, aber ich denke, das ist nur Javascript. Die Verwendung von getUTCDay() gibt die korrekten Werte zurück. Mann, jetzt kann ich schlafen gehen. Danke allen! – magreenberg

+0

@ magreenberg-es gibt nur ein "gültiges" Format. Implementierungen können frei tun, was sie wollen, mit allem, was nicht konform ist. – RobG

Verwandte Themen