当我使用矩进行解析时，Moment.js 2个不同的日期字符串给出相同的值

Question

I am parsing 2 different date strings

var d1  = '2014-02-01T00:00:00.000+0530'

var d2 = '2014-02-23T00:00:00.000+0530'   

when i parse them using moment

alert(moment(d1, 'YYYY-MM-dd"T"HH:mm:ss.fffffff"Z"').toDate());
alert(moment(d2, 'YYYY-MM-dd"T"HH:mm:ss.fffffff"Z"').toDate());

both of them print Sat Feb 1 2014 xxxxx

what is wrong with it??

here is the link to the fiddle i created

jsfiddle

Answer 1

I think your moment formatting string is causing you the problem. If I remove this, the dates do not print as the same.

http://jsfiddle.net/K5ub8/7/

EDIT: The specific issue is you are using dd for day, instead of DD . http://momentjs.com/docs/#/parsing/string-format/

Here is your fiddle fixed: http://jsfiddle.net/K5ub8/9/

However, I am not 100% sure about the fractional seconds, I believe it is SSS instead of fffffff but I would test this if you need to cater for fractional seconds.

I should mention that if you are converting it back into a JavaScript date object anyway with toDate() , then you don't really need the moment formatting parameter as the date will be formatted in JSON Date format.

I would question why you would want to generate a moment formatted date, and then convert it back to JavaScript, a normal practice might be to receive a date in JavaScript format, then create a moment object which you can use to perform calculations and display in a nice user friendly way.

Answer 2

Simple answer: your format was off a bit.

http://jsfiddle.net/K5ub8/8/

After tweaking the format to be 'YYYY-MM-DDTHH:mm:ss.SSSZZ' rather than 'YYYY-MM-dd"T"HH:mm:ss.fffffff"Z"' it worked just fine. When you're trying to debug issues like this, it's always good to keep the format in a separate variable so you can use the same format that you're trying to parse out to display what you're getting. Had you done that, you would have noticed that 'YYYY-MM-dd"T"HH:mm:ss.fffffff"Z"' was messed up due to it printing out 2014-01-Fr"T"11:32:03.fffffff"-08:00" . Which obviously isn't quite right.