Unexpected Date.parse behaviour

[willholley]

QuickJS appears to unexpectedly parse date strings containing epoch seconds, unlike other major JS engines.

For example, attempting to parse string containing "1065873600" (Saturday, October 11, 2003 12:00:00 PM):

qjs > Date.parse("1065873600")
946684800000

946684800000 represents Saturday, January 1, 2000 12:00:00 AM, which is incorrect.

In other JavaScript engines (e.g. SpiderMonkey, V8), Date.parse("1065873600") returns NaN, so I expected similar behavior from qjs.

I appreciate that the specification of Date.parse allows for implementation-specific fallbacks - I just couldn't find a description of the intended behavior so better understand whether this is intended behavior or a bug.

[bnoordhuis]

I don't know if I'd call it a bug, more like GIGO (Garbage In, Garbage out.) Pull request welcome, I'd say.

What happens is that js_date_parse_otherstring parses the first 9 digits as a timestamp, then sees the final "0" and interprets that as a short-version year, superseding the timestamp, hence January 1, 2000.

[nickva]

I tried to fix it upstream and since it's the same change made pr here as well #967