/* 1. Gets the local date time in ISO-8601 format. ex: “2015-12-11T18:52:59-05:00” */
var localDateTime = moment().format();

/* 2. POST to the API Body: { date: “2015-12-11T18:52:59-05:00” } */

/* 3. On Server convert the localtime to UTC: “2015-12-11T23:52:59+00:00” */
var UTCTime = moment.utc(req.body.date).format();

/* 4. Store the UTCTime in the DB. */

/* 5. Returned to the user in an JSON */
/* res.json( { date: “2015-12-11T23:52:59+00:00” } ); */

/* 6. Testing in the Browser: */
var localDateTime2 = moment(“2015-12-11T23:52:59+00:00”).format();

/* Assert we got a UTC that converts back into a local time we originally sent. */
localTime == localTime2

This should be to specific moment commands for local and server side dates.

Anyone?

Store two forms of the date. One in UTC to enable sorting/searching across timezones, and one to store the user’s actual intent. This last form may actually require two fields in most databases; one to store the local (to the user) datetime and one to store the user’s timezone.

This is also the suggestion w3c makes:
http://www.w3.org/TR/timezone/

“When creating an application that can store values in the future, including recurring events, you’ll need to make additional data fields to ensure that you can reconstruct the user’s intentions and adapt future time values to changes in time zones and time zone rules (especially alteration of daylight saving/summer time start and stop).”