If ecma_date_parse_year got an invalid date string, it could overread the input string.
The problem was that we compared the original str_p to str_end_p instead of str_start_p.
Additionally I simplified the parser loop.
Fixes#3388.
JerryScript-DCO-1.0-Signed-off-by: Csaba Osztrogonác oszi@inf.u-szeged.hu
Changes:
- Parse output of Date.prototype.toString() and Date.prototype.toUTCString()
- Date.prototype.toString() is ECMA-262 v9 conform now, only TZ part changed
(Before ECMA-262 v9 it was implementation-dependent.)
- Reused day_names_p and month_names_p arrays (and made them more efficient)
- Tests updated and new tests added
Fixes#2946.
JerryScript-DCO-1.0-Signed-off-by: Csaba Osztrogonác oszi@inf.u-szeged.hu
This PR is the preparation of the #2946 issue.
(Date.parse() should handle UTC date string format)
Changes:
- Handle min/max values in ecma_date_parse_date_chars function instead of code duplication
- Parse special characters in the new ecma_date_parse_special_char function
- Additionally fixed two parsing issue: invalid formats should be refused
JerryScript-DCO-1.0-Signed-off-by: Csaba Osztrogonác oszi@inf.u-szeged.hu
ES5.1 15.9.1.15 Note1 defines that 24:00 is same as 0:00
of the next day. The spec explicitly doesn't mention that
24:01 should be invalid, but it should be self-evident.
(FireFox and Chrome also refuses times bigger than 24:00)
JerryScript-DCO-1.0-Signed-off-by: Csaba Osztrogonác oszi@inf.u-szeged.hu
ES5.1 15.9.4.2 specifies that Date.parse (string) has to accept
at least Date Time String Format: YYYY-MM-DDTHH:mm:ss.sssZ. But
the spec allows implementation-specific fallbacks. Additionally
ES5.1 15.9.1.15.1 specifies Extended years format, but isn't
explicitly required to be accepted by Date.parse. But ES6 already
clarified that Date.parse has to accept extended years format too.
JerryScript-DCO-1.0-Signed-off-by: Csaba Osztrogonác oszi@inf.u-szeged.hu
Since the project is now hosted at the JS Foundation we can move to unified copyright notices for the project.
Starting with this commit all future contributions to the project should only carry the following copyright notice (except for third-party code which requires copyright information to be preserved):
"Copyright JS Foundation and other contributors, http://js.foundation" (without the quotes)
This avoids cluttering the codebase with contributor-specific copyright notices which have a higher maintenance overhead and tend to get outdated quickly. Also dropping the year from the copyright notices helps to avoid yearly code changes just to update the copyright notices.
Note that each contributor still retains full copyright ownership of his/her contributions and the respective authorship is tracked very accurately via Git.
JerryScript-DCO-1.0-Signed-off-by: Tilmann Scheller t.scheller@samsung.com
