3 ms·

I don't know if this is only true of JavaScript, but its parser at least accepts all months as having 31 days and then normalises them to the following month, o

I don't know if this is only true of JavaScript, but its parser at least accepts all months as having 31 days and then normalises them to the following month, on overflow: > new Date('2015-02-31') Mon Mar 02 2015 00:00:00 GMT+0000 (GMT) > new Date('2015-02-32') Invalid Date I'm not sure if I entirely approve of this behaviour...

dspillett 11y ago
The by-integers constructor accepts overflow on any of the input values and adjusts accordingly: > new Date(2015,10,30) Mon Nov 30 2015 00:00:00 GMT+0000 (GMT Standard Time) > new Date(2015,10,31) Tue Dec 01 2015 00:00:00 GMT+0000 (GMT Standard Time) > new Date(2015,10,32) Wed Dec 02 2015 00:00:00 GMT+0000 (GMT Standard Time) > new Date(2015,10,320) Thu Sep 15 2016 00:00:00 GMT+0100 (GMT Daylight Time) > new Date(2015,10,01,23,59) Sun Nov 01 2015 23:59:00 GMT+0000 (GMT Standard Time) > new Date(2015,10,01,23,590) Mon Nov 02 2015 08:50:00 GMT+0000 (GMT Standard Time)
- Xophmeister 11y ago
  I can kind of justify that, insofar as it's unlikely that any input would be entered directly like that and it has the quite nice property of allowing date arithmetic on an arbitrary unit (e.g., "+ 1 calendar month, 4 hours and 25 milliseconds", etc.)
  - dspillett 11y ago
    Yes, I've deliberately used it that way in the past: newDate = new Date(refDate.getFullYear(), refDate.getMonth(), refDate.getDate(), refDate.getHours()+1000, refDate.getMinutes()) letting it deal with the wrapping of larger date/time parts as needed.
jcranmer 11y ago
Actually, the JS specification doesn't constrain the date parser except to require that ISO 8601 dates must be accepted, so it differs from JS engine to JS engine. I'm guessing you're testing in V8, since my SpiderMonkey test right now gave Invalid Date for both of those. It got really annoying for me because the ISO 8601 portion of the parser refused to accept leap seconds but non-ISO-8601 forms (such as RFC 5322) did.

dspillett 11y ago

The by-integers constructor accepts overflow on any of the input values and adjusts accordingly: > new Date(2015,10,30) Mon Nov 30 2015 00:00:00 GMT+0000 (GMT Standard Time) > new Date(2015,10,31) Tue Dec 01 2015 00:00:00 GMT+0000 (GMT Standard Time) > new Date(2015,10,32) Wed Dec 02 2015 00:00:00 GMT+0000 (GMT Standard Time) > new Date(2015,10,320) Thu Sep 15 2016 00:00:00 GMT+0100 (GMT Daylight Time) > new Date(2015,10,01,23,59) Sun Nov 01 2015 23:59:00 GMT+0000 (GMT Standard Time) > new Date(2015,10,01,23,590) Mon Nov 02 2015 08:50:00 GMT+0000 (GMT Standard Time)

Xophmeister 11y ago
I can kind of justify that, insofar as it's unlikely that any input would be entered directly like that and it has the quite nice property of allowing date arithmetic on an arbitrary unit (e.g., "+ 1 calendar month, 4 hours and 25 milliseconds", etc.)
- dspillett 11y ago
  Yes, I've deliberately used it that way in the past: newDate = new Date(refDate.getFullYear(), refDate.getMonth(), refDate.getDate(), refDate.getHours()+1000, refDate.getMinutes()) letting it deal with the wrapping of larger date/time parts as needed.

jcranmer 11y ago

Actually, the JS specification doesn't constrain the date parser except to require that ISO 8601 dates must be accepted, so it differs from JS engine to JS engine. I'm guessing you're testing in V8, since my SpiderMonkey test right now gave Invalid Date for both of those. It got really annoying for me because the ISO 8601 portion of the parser refused to accept leap seconds but non-ISO-8601 forms (such as RFC 5322) did.