Date parsing deviates from Chrome #11151

emirkin opened this Issue Mar 19, 2013 · 17 comments


None yet
emirkin commented Mar 19, 2013

Best shown by example:

phantomjs> new Date("May 8")
"Invalid Date"
phantomjs> new Date("May 8 2013")

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


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 commented Mar 19, 2013

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


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

emirkin commented Mar 19, 2013

Good to know!
When is 2.0 roughly expected?


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.

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 GitHub


@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!


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.


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


+1 Running into the same issue.

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

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


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


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


Think I found another one.

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

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

tupton commented Sep 30, 2014

@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")

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.

@davisford davisford referenced this issue in sorribas/phantom-render-stream Oct 27, 2014

add support for injecting polyfills #66

@petermuessig petermuessig added a commit to SAP/openui5 that referenced this issue May 15, 2015
@petermuessig petermuessig [INTERNAL] QUnitUtils: Workaround for Date parse issues on PhantomJS
Bug is already reported here:

Change-Id: I8039aa817fd2a8d5aae148cd9829f0c3143226bb
jnu commented Jun 25, 2015

@jdelibas that one appears to be Able to reproduce in Phantom 2.

@Vitallium Vitallium added Webkit and removed old.Domain-WebKit labels Apr 30, 2016

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')       
phantomjs> new Date('2034-03-01')
phantomjs> new Date('2100-02-28')
phantomjs> new Date('2100-03-01')

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:


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


Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment