Date parsing deviates from Chrome

[emirkin]

Best shown by example:

phantomjs> new Date("May 8")
"Invalid Date"
phantomjs> new Date("May 8 2013")
"2013-05-08T07:00:00.000Z"

In Chrome, both strings are parsed into the same date. Thoughts?

[JamesMGreene]

We've had to deal with WebKit Date parsing bugs in the past, this is likely just another one of those. Search the issue tracker for "date" to see more of these.

[emirkin]

No doubt. This exact case (ie "when year missing") doesn't seem to be addressed.

[vitallium]

Actually, May 8 is invalid date format according to spec (ISO 8601) and EcmaScript (http://es5.github.com/#x15.9.1.15).
But, this will be resolved in 2.0 release (after upgrading to Qt5 and the latest WebKit version).
Related issue: #10187

[emirkin]

Good to know!
When is 2.0 roughly expected?

[JamesMGreene]

Assuming we can pull off the Qt 5.0 upgrade in a single release cycle (as
planned), then PhantomJS 2.0 will be released on June 21, 2013.

Sincerely,
James Greene

On Tue, Mar 19, 2013 at 1:47 PM, Eugene Mirkin notifications@github.comwrote:

Good to know!
When is 2.0 roughly expected?

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/11151#issuecomment-15135115
.

[JamesMGreene]

@zicjin: We love the enthusiasm but that alone won't help us get PhantomJS 2.0 out the door any faster. If you want to see it ready sooner, dive in and lend a hand!

[kevinparkerson]

If it helps at all, I've found phantomjs spits out 'Invalid Date' when attempting to use a timeZone offset other than 'Z'. For example:

window.console.log(new Date('2050-03-31T00:00:00-0500'));

That will output 'Invalid Date', while this works just fine:

window.console.log(new Date('2050-03-31T00:00:00Z'));

Doesn't help me solve the issue of my unit tests bombing in phantomjs when they shouldn't be, but figured I'd might as well share.

[kbaltrinic]

Don't know if this will help you but I found this issue while researching another PhantomJS date parsing problem we were having. To fix ours I completed a polyfill that "successfully" overrides Date.parse and the Date contructor. I say "sucessfully" because of course, the constructor override is necessarily a hack. It solves our issue and I though you might be able to tweak to address yours. YMMV

https://github.com/kbaltrinic/PhantomJS-DatePolyfill

[Duder-onomy]

+1 Running into the same issue.

new Date(120).toLocaleTimeString('en-US', {hour12: true});

expected: 4:00:00 PM
actual: 16:00:00

[kcrwfrd]

@kevinparkerson's interim solution worked perfectly for me, thanks!

[gonzofish]

thanks @kevinparkerson I thought I could do that, but you just confirmed it for me!

[jdelibas]

Think I found another one.

new Date("2034-03-25");

Expected
Sat Mar 25 2034 00:00:00 GMT+0000 (GMT Standard Time)
PhantomJS
Fri Mar 24 2034 00:00:00 GMT+0000 (GMT Standard Time)

[tupton]

@jdelibas Is the machine you're testing on in a timezone that's behind GMT? I get similar output in Chrome. It's implicitly adding "T00:00Z" – i.e. it's assuming GMT – and then returning the date in whatever timezone your environment thinks it is. I think that's expected, and not the same bug as here.

What is the same bug is if you try to specify a timezone other than GMT in phantomjs:

phantomjs> new Date("2034-03-25T00:00-0500")
"Invalid Date"
phantomjs> new Date("2034-03-25T00:00Z")
"2034-03-24T00:00:00.000Z"

In Chrome:

> new Date("2034-03-25T00:00-0500")
Sat Mar 25 2034 00:00:00 GMT-0500 (CDT)
> new Date("2034-03-25T00:00Z")
Fri Mar 24 2034 19:00:00 GMT-0500 (CDT)

Note that Chrome displays the date in my local timezone, even though I created it using GMT.

My rule of thumb is that any date without a timezone is inherently wrong or at the very least incomplete. That's why this bug is such a hassle, but at least converting everything to GMT is a valid, if tedious, workaround.

[jnu]

@jdelibas that one appears to be https://bugs.webkit.org/show_bug.cgi?id=130123. Able to reproduce in Phantom 2.

[davidlehn]

PhantomJS 2.1.1 still has the WebKit bug referred to by @jnu. It was fixed in WebKit on 2014-03-14. Parsed dates from 2034-03-01 to 2100-02-28 are wrong.

phantomjs> new Date('2034-02-28')       
"2034-02-28T00:00:00.000Z"
phantomjs> new Date('2034-03-01')
"2034-02-28T00:00:00.000Z"
phantomjs> new Date('2100-02-28')
"2100-02-27T00:00:00.000Z"
phantomjs> new Date('2100-03-01')
"2100-03-01T00:00:00.000Z"

[wallw-teal]

We are still seeing date inconsistencies with Chrome for the following values (the local timezone is -0700):

phantomjs> new Date('2014-01-30 12:34:56')
Invalid Date
phantomjs> new Date('2014-01-30T12:34:56+0000')
Invalid Date
phantomjs> new Date('2014-01-30T12:34:56-0700')
Invalid Date

Chrome parses those as:

2014-01-30T19:34:56Z
2014-01-30T12:34:56Z
2014-01-30T19:34:56Z

[seyDoggy]

I'm glad I found this thread. I've been trying to render a page with charts on it, and you can imagine how many Date objects get used. Nothing was working, I thought I was going crazy until I ran:

phantom> new Date('2017-01-13 01:14')
Invalid Date

WAT?

[wgroeneveld]

We're using the beta Phantom 2.5 build and dates are still fucked up so the Qt update did nothing to fix any of that. Trying to compare dates (somedate < currdate) to see which one is in the past works 1 out of 5 runs... We're running jasmine on top of Phantom so our tests are becoming flaky due to this issue.

Any progress or updates?

[AkA84]

Running BackstopJS (which is using PhantomJS to work) and I encountered this error as well and I can't take diff screenshots of certain pages anymore.

Any updates?

[ktiedt]

Consider this the semi annual, "it is still broken and some feedback would be amazing" comment.

[wallw-teal]

@ktiedt try headless Chrome/Firefox instead. I believe the addition of that flag to those browsers has rendered this project obsolete.

https://developers.google.com/web/updates/2017/04/headless-chrome
https://developer.mozilla.org/en-US/Firefox/Headless_mode

[ktiedt]

@wallw-bits yeah after posting, I learned that Phantom is no more, thanks for the links, those I had not come across yet.

[stale]

Due to our very limited maintenance capacity (see #14541 for more details), we need to prioritize our development focus on other tasks. Therefore, this issue will be automatically closed. In the future, if we see the need to attend to this issue again, then it will be reopened. Thank you for your contribution!