Date.parse and new Date() fail on valid formats - by ckozl

Status : 

  Not Reproducible<br /><br />
		The product team could not reproduce this item with the description and steps provided.<br /><br />
		A more detailed explanation for the resolution of this particular item may have been provided in the comments section.

ID 776783 Comments
Status Closed Workarounds
Type Bug Repros 2
Opened 1/17/2013 6:35:07 AM
Access Restriction Public


---excerpt from: []

"The value of an absent time zone offset is “Z”."


IE10's behavior: 
>> Date.parse('2011-11-29T15:52:18.867') === Date.parse('2011-11-29T15:52:18.867Z') 


this is incorrect and contrary to what the ECMA spec states for date parsing of ISO8601 strings.  Other browsers have been doing this correctly for a while now (Opera and Chrome both are standards compliant in this regard), it'd be nice if IE didn't need a shim to bring it up to standards compliant behavior.


this also runs contrary to your own documentation:

"Z   The value in this position can be one of the following. If the value is omitted, UTC time is used.

Z indicates UTC time.
+hh:mm indicates that the input time is the specified offset after UTC time.
-hh:mm indicates that the input time is the absolute value of the specified offset before UTC time."

-- why was this closed as non-reproducible?  

Sign in to post a comment.
Posted by ckozl on 10/20/2014 at 7:25 AM
Is everyone illiterate on this site?

1) Always broken never fixed
2) Spec / MSDN doc violation
3) Chrome + Safari both handle this correctly (only IE and FF are left out in the cold)
Posted by Alexei Mihalchuk on 1/18/2013 at 4:06 AM
Hmm, I just tried this in IE9 and IE9 returns true.
IE10 in W8 returns false.
So it appears to be a regression.

Maybe you should re-open the bug.
Then they can close it as Won't Fix, but then they can at least verify it again.
Posted by ckozl on 1/17/2013 at 8:52 AM
correction: i mean "standards-compliant way" not "stands-compliant"

please reconsider this bug for a future release... it would be nice to get something like this compliant with a standard early on, especially seeing how dates in JavaScript are so terrible. Also, since your own documentation @ [], I would assume it was Microsoft's intention to have it behave this way...
Posted by ckozl on 1/17/2013 at 8:45 AM
I just re-read this, no where did i say that firefox and safari acted the correct, stands-compliant way... i merely said "other browsers have been doing this for awhile"

i hold IE and chrome to a higher standard than firefox and desktop safari (i don't even file bug reports for those browsers). IE and Chrome constitute almost 100% of the enterprise desktop users, that I deal with.

And in the mobile space, mobile safari passes this test with flying colors. I have no clue why there is a discrepancy with desktop version of the browser for windows, you'll have to ask Apple. I will attach the screenshot of it passing the test on an iphone in mobile safari.
Posted by ckozl on 1/17/2013 at 8:25 AM
That really doesn't matter what firefox and safari do, i'm sorry if i misspoke i will edit the bug report... it is still both a spec violation and runs contrary to your own MSDN documentation
Posted by Microsoft on 1/17/2013 at 8:08 AM
Thank you for your feedback.

We are currently unable to reproduce this issue as described.

IE10Win7, IE10Win8, FF and Safari all return False statements. The only true statement is returned from Chrome.

We value your feedback. If you have additional information that can help us recreate this issue — such as a specific url, more detailed steps, test results from different machines, or additional conditions — please reactivate the bug or submit a new bug with more details on how to reproduce the issue. You can also read the guidelines at regarding filing a good bug report.

Best regards,

The Internet Explorer Team