Repository navigation
Conversation
In date strings that aren't in the ISO format, the time is parsed and then string_skip_separators() skips '-', so a negative UTC offset that follows the time directly lost its sign and was read as another time: "2000-01-01 10:00:00-05:00" (the format of Python's str(datetime)) gave 05:00 local time instead of 15:00Z, and "...10:00:00-0500" was read as the year 500. Positive offsets were parsed correctly. An offset after the time is now parsed before skipping separators. string_get_milliseconds() stopped after 9 fraction digits, leaving the rest to be read as the next field: "...10:00:00.123456789123+05:00" gave the year 123, and an ISO string with 10 or more digits was NaN. The extra digits are now consumed and ignored, like those after the third.
This branch has not been deployed
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
For date strings that aren't in the ISO format,
js_date_parse_otherstring()parses the time and then callsstring_skip_separators(), which skips-. A negative UTC offset directly after the time therefore loses its sign, and the next iteration reads the rest as another time or as a year:Date.parse(s)2000-01-01 10:00:00-05:002000-01-01T15:00:00.000Z2000-01-01 10:00:00.250-05:002000-01-01T15:00:00.250Z2000-01-01 10:00:00-05000500-01-01T10:00:00(year 500)2000-01-01T15:00:00.000ZJan 1 2000 10:00:00-05000500-01-01T10:00:002000-01-01T15:00:00.000Z2000-01-01 10:00:00-05NaN2000-01-01T15:00:00.000ZThe first form is what Python's
str(datetime)produces for an aware datetime, and PostgreSQL printstimestamptzwith an offset like-05. Positive offsets were already parsed (+05:00works), because+isn't a separator. The time branch now continues with the next iteration when the time is directly followed by+or-. The existing sign handling then parses it as an offset, since a time has been seen.string_get_milliseconds()also stopped after 9 fraction digits, leaving the rest to be parsed as the next field:2000-01-01 10:00:00.123456789123+05:00gave the year 123, and an ISO string with 10 or more digits, such as2020-01-01T01:01:01.1234567891Z, wasNaN. Digits after the third already don't change the value (mulis 0 by then), so the extra digits are now consumed and ignored like the others.Tests:
test_dateintests/test_builtin.jschecks the strings above (negative offset with and without milliseconds,-0500,-05,+05:00, theJan 1 2000form, and long fractions in both parsers). The new negative-offset checks fail without the change.run-test262 -c tests.confpasses, and so do test262'sbuilt-ins/Datetests.