Date constructor: numeric arguments vs. string argument giving different dates in some cases

后端 未结 5 1944
孤街浪徒
孤街浪徒 2021-01-01 16:18

First of all, I think timezone probably has something to do with this. I\'m in EST/EDT. Also, I\'m testing this on chromium 17 / linux.

Now, let\'s say I create two

相关标签:
5条回答
  • 2021-01-01 16:20

    Using "-" as a date separator for USA dates confuses some browsers, some will perform date arithmetic others will return NaN, so use the "/" date separator. A culture aware solution is to use date.js, which is an outstanding JavaScript date handler that resolves issues like the one you have pointed out (http://www.datejs.com/). Using the parse method removes all confusion:

    Date.parse("2020-12-15").toString() // yields the correct date ("Tue Dec 15 00:00:00 PST 2020"). 
    
    0 讨论(0)
  • 2021-01-01 16:28

    relaying on this post, it seems that the Date's string argument constructor is implementation sensitive, due to various Date.parse() implementations by browsers.

    your measurements are correct, and you probably should avoid using this constructor altogether, if you wish your browser to parse EST correctly.

    0 讨论(0)
  • 2021-01-01 16:29

    After looking in V8's source code:

    // Specification:
    // Accept ES5 ISO 8601 date-time-strings or legacy dates compatible
    // with Safari.
    <...>
    //  A string that matches both formats (e.g. 1970-01-01) will be
    //  parsed as an ES5 date-time string - which means it will default
    //  to UTC time-zone. That's unavoidable if following the ES5
    //  specification.
    

    Reading the surrounding code, it seems that a date-time string with both month and day 2 symbols long is considered a valid ES5 date-time string. Further down in the ES5 parser, after it parses the dates and times, there's a comment:

    // Successfully parsed ES5 Date Time String. Default to UTC if no TZ given.
    

    In case of "YYYY-MM-DD", once the code gets that far, the ES5 parser has successfully parsed the entire string, so it returns before the legacy parser gets a chance to localize the timezone. Otherwise (month/day are one symbol long) it's treated as a "legacy" datetime and the legacy parser gets to deal with it and localize it.

    0 讨论(0)
  • 2021-01-01 16:34

    Here's a simplified answer drawing from the other answers.

    Date recognizes different string formats

    • Nonstandard dates
    • RFC 2282 dates
    • ES 5 dates

    Most formats are interpreted as local dates

    On page 14 of RFC 2282, we see:

    The date and time-of-day SHOULD express local time.

    Nonstandard dates are treated in similar fashion.

    ES 5 format is interpreted as UTC

    In section 15.9.1.15 of the ES 5 spec we see:

    The value of an absent time zone offset is “Z”.

    "Z" represents UTC time.

    The tenth of October

    ES 5 formatted dates require double-digit months and days. The months and days in the original post are not zero-padded. "2020-9-9" is not a valid ES 5 date representation; it's a non-standard format, so it's interpreted in local time. "2020-10-10" is a valid ES 5 date representation, so it must be interpreted in UTC.

    Possible workarounds

    • Don't use the string constructor / Date.parse!
    • Change the separator character so the format never matches the ES 5 format.
    • Specify a timezone.
    • Adjust dates to local time. If they have hours or minutes: date.setMinutes(date.getTimezoneOffset()); (this seems to work, anyway).
    0 讨论(0)
  • 2021-01-01 16:40

    It looks like the date constructor requires spaces rather than '-'. Its the recommended way. Check out this link:
    3.3. Date and Time Specification

    Though foldingwhite space is permitted throughout the date-time specification, it is RECOMMENDED that a single space be used in each place that FWS appears (whether it is required or optional)

    Also check out this link:
    https://developer.mozilla.org/en/JavaScript/Reference/Global_Objects/Date

    dateString: String value representing a date. The string should be in a format recognized by the parse method (IETF-compliant RFC 2822 timestamps).

    I tried following code and it returns true

    dateFromNumbers = new Date(2020, 11, 15);
    dateFromString = new Date("2020 12 15");
    alert(+dateFromNumbers == +dateFromString);​
    

    Also its not a problem start with the month of October, it has do with the double digit months. If I try the same method with September then:

    dateFromNumbers = new Date(2020, 8, 15);
    dateFromString = new Date("2020-09-15");
    alert(+dateFromNumbers == +dateFromString);​ // This returns false
    

    But if I use single digit for September then it returns true

    dateFromNumbers = new Date(2020, 8, 15);
    dateFromString = new Date("2020-9-15");
    alert(+dateFromNumbers == +dateFromString);​ // This returns true
    

    And if use space with double digit September, then it returns true

    dateFromNumbers = new Date(2020, 8, 15);
    dateFromString = new Date("2020 09 15");
    alert(+dateFromNumbers == +dateFromString);​//This returns true
    
    0 讨论(0)
提交回复
热议问题