Date parsing deviates from Chrome #11151

Open
emirkin opened this Issue Mar 19, 2013 · 17 comments

Projects

None yet
@emirkin
emirkin commented Mar 19, 2013

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
Collaborator

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

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

@Vitallium
Collaborator

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

Good to know!
When is 2.0 roughly expected?

@JamesMGreene
Collaborator

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/ariya/phantomjs/issues/11151#issuecomment-15135115
.

@JamesMGreene
Collaborator

@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

@kvcrawford

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

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

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:
ariya/phantomjs#11151

Change-Id: I8039aa817fd2a8d5aae148cd9829f0c3143226bb
ddd8360
@jnu
jnu commented Jun 25, 2015

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

@Vitallium Vitallium added Webkit and removed old.Domain-WebKit labels Apr 30, 2016
@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-bits

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?

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