Confusion over moment.utz with MySQL DateTime

[tanepiper]

I've written a small test here: https://jsfiddle.net/vrdhcuey/1/

When we request from the database we get a DATETIME from the MySQL database back (initially set to default UTC timezone but also tested with it set as Europe/Dublin as timezone) of 2016-04-22T16:00:00.000Z - that is to say the end datetime of our object is Friday 22nd April, at 4pm. This is in reality timezoneless as all we are saying is that the event can end at 4pm on a given date, but that date could fall in GMT or BST.

In the test provided, we want to get the duration between now and that datetime. However it is always an hour off. The only way around it is to remove the .000Z from the end of the datetime string. I've also tried to use moment.tz but have the same result (i.e. in this test leftTime4 is the correct behavior we're expecting). I would have however expected leftTime2 to work as is.

Can anyone please clear up this confusion, or am I hitting a bug here?

[maggiepint]

The ISO8601 standard specifies that dates ending in Z shall be interpreted as UTC. As such, what moment does when passed your time is convert the time from UTC to local. This is how you get your one hour off situation.

If you wish for moment to ignore the Z (interpret the time as local), you can specify a format that does not pick up on the Z by doing the following:

moment('2016-04-22T16:00:00.000Z', 'YYYY-MM-DDTHH:mm:ss.SSS').format()

If you want more information about the various parsing modes, this section of the guides may be helpful: http://momentjs.com/guides/#/parsing/local-utc-zone/

[mattjohnsonpint]

Right - so, the real fix is, don't emit Z from your back end if you don't really mean UTC.

[tanepiper]

@mj1856 Yea tried to, but I wonder if the issue lies with Sequlize rather than MySQL itself - when we run the query against the DB directly it emits just a plain DATETIME with YYYY-MM-DD HH:MM:SS, as it's stored. Changing the timezone of the DB seemed to make no difference. Anyway the above seems to fix it for now, we'll see if it holds up when we go back into GMT :bomb: