All numbers must be base 10. If the MM or DD fields are absent ā01ā is used as the value. If the HH, mm, or ss fields are absent ā00ā is used as the value and the value of an absent sss field is ā000ā. The value of an absent time zone offset is āZā.
Thanks for the reference! This explains the behavior described in the original post.
However, I then argue that this standard is bad. Though I'm having trouble finding any truly official documentation, everything I do find (e.g., Wikipedia and this document) says that according to ISO 8601, in the absence of a time zone, local time should be used, not UTC. So, the browser is behaving correctly with these bare dates, but based on what I argue is a flawed standard that conflicts with ISO 8601.
Even more bothersome, though, is that this still doesn't explain why adding an explicit time switches to local time instead of UTC! I looked at the document linked, not just the quote, but still as far as I can tell, the standard you linked seems to indicate that new Date('1995-12-17T00:00:00') should still be considered UTC and result in Sat Dec 16 1995 17:00:00 GMT-0700 (MST), but it is read in local time instead!
This makes me sad. I don't understand why this is.
What's more troublesome is that that is inconsistent across different browsers: new Date('1995-12-17T00:00:00') is parsed as UTC on Safari.
According to the specs, strings that do not confirm to ISO 8601 are open for interpretation by difference implementation (like April 13 is April 13 2001 on Chrome, but doesn't work on other browsers). So my first guess was that this string just did not register as ISO 8601 on Chrome and it fell back to its own Interpretation.
I went to the latest ES7 specs and it has changed:
When the time zone offset is absent, date-only forms are interpreted as a UTC time and date-time forms are interpreted as a local time.
So we can have different results based on what version of the browser we are using.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
Here's a quote from the ECMAScript 5 specification:
So a lack of timezone offset is treated as UTC.
Thanks for the reference! This explains the behavior described in the original post.
However, I then argue that this standard is bad. Though I'm having trouble finding any truly official documentation, everything I do find (e.g., Wikipedia and this document) says that according to ISO 8601, in the absence of a time zone, local time should be used, not UTC. So, the browser is behaving correctly with these bare dates, but based on what I argue is a flawed standard that conflicts with ISO 8601.
Even more bothersome, though, is that this still doesn't explain why adding an explicit time switches to local time instead of UTC! I looked at the document linked, not just the quote, but still as far as I can tell, the standard you linked seems to indicate that
new Date('1995-12-17T00:00:00')should still be considered UTC and result inSat Dec 16 1995 17:00:00 GMT-0700 (MST), but it is read in local time instead!This makes me sad. I don't understand why this is.
What's more troublesome is that that is inconsistent across different browsers:
new Date('1995-12-17T00:00:00')is parsed as UTC on Safari.According to the specs, strings that do not confirm to ISO 8601 are open for interpretation by difference implementation (like
April 13is April 13 2001 on Chrome, but doesn't work on other browsers). So my first guess was that this string just did not register as ISO 8601 on Chrome and it fell back to its own Interpretation.I went to the latest ES7 specs and it has changed:
So we can have different results based on what version of the browser we are using.