get UTC date (not UTC string) in javascript

Question

I want to get utc date using moment or any other possibilities. utcString = moment.utc(someDate)).format() is giving utc string not utc date. I am not able to perform operations like utcString.getDate() , etc using this. Please help me in providing with utc date object.

moment.utc(new Date()).toDate() is converting date again to my local time.

for example: I want the string of utc format like "2019-10-31T00:00:00.000Z" to get converted to utc date and perform operations(like getDate(), getFullYear(), etc) which could be performed using Date() object

Answer 1

From the MDN Documentation on the Date object:

Creates a JavaScript Date instance that represents a single moment in time in a platform-independent format. Date objects contain a Number that represents milliseconds since 1 January 1970 UTC.

In other words, the Date object is simply an abstraction that contains a single value, and that value always in terms of UTC. If you want to see that value, call either .valueOf() or .getTime(), or coerce it to a Number (ex: +d).

There are many features of the Date object that can expose that value in different ways, such as in a standardized string format, a human readable string format, or various other numbers that represent partial component values (ie. year, month, day, hour, minute, second, millisecond). Some of these functions use UTC when determining their output (such as .toISOString(), .getUTCFullYear(), etc.), and others use the computer's local time zone when determining their output (such as .toString(), .getFullYear(), etc.).

It's easy to get confused by this, especially if calling console.log directly on a Date object. The thing to remember there is that the console logging functionality is implementation specific. You may see a human readable string that looks like local time as if you called .toString(), but some implementations give you a string that looks like UTC time in ISO format as if you called .toISOString(). Really, the implementation can do whatever it wants when it comes to logging. It could print out a hissing cat.

To add to the confusion, the Date constructor takes its numeric parameters in terms of local time, so one might think new Date(2019,8,5,0,0,0) was a Date object in local time, but actually it's converting to UTC during construction and recording the corresponding timestamp. One can pass new Date(Date.UTC(2019,8,5,0,0,0)) to have those values interpreted as UTC, but the Date object itself is in UTC either way.

The key point is, don't think that because you see local time that the Date object is in local time. It isn't. It never is. Thus, asking for it in a different time zone is also not possible. Asking for it in UTC is what you already have.

I want the string of utc format like "2019-10-31T00:00:00.000Z" to get converted to utc date and perform operations(like getDate(), getFullYear(), etc)

You wouldn't call getDate or getFullYear. Those functions internally ask for the computers's local time zone and apply it to the timestamp before determining their result. Instead you would call for getUTCDate or getUTCFullYear, which do not apply the local time zone.

... Actually I am using react-date-picker. ... (from your comments)

There are lots of date pickers out there. If you don't get the functionality out of the one you're using, try another.

The best ones will do one of two things when it comes to time zones:

• They might offer a setting for the "mode" of the picker, typically either local or UTC, or perhaps a specific UTC offset or time zone ID. This would allow you to pre-determine how you want the picker to behave with regard to its inputs and outputs.

• They might simply provide the input and output as a String, rather than as a Date object. This would allow the picker to behave in a neutral way, and you would then interpret the user's selection in whichever manner you pleased. (BTW, HTML5's <input type="date"> works this way.)

Unfortunately, there are lots of date pickers that don't work that way and assume you simply want a Date object that is created based on local time. To contend with that, you will need to lie a little bit.

For example, say I pick 2019-09-05 from a date picker that assumes my local time zone. It does internally new Date(2019, 8, 5), or perhaps it does new Date("2019-09-05T00:00:00.000"). Either form would be interpreted as local time before the the Date object records the corresponding timestamp value. But I didn't actually want that - I wanted the user to pick a UTC date. So I add this bit of code to adjust the object (d) returned from the picker:

d.setTime(d.getTime() - (d.getTimezoneOffset() * 60 * 1000));

This technique is called epoch shifting, as it shifts the basis of the timestamp away from (or towards) the 1970-01-01T00:00:00.000Z Unix epoch. In this case, it's the original Date object (the one created by the picker) that was created incorrectly, and thus the above shifts it back to the standard Unix epoch.

Keep in mind that this technique is all about having your user pick a UTC-based value, and get it back to a regular Date object. It is not to be used to have your user pick a local-value and convert it to UTC. For that you must used the functions designed for that purpose (getUTCFullYear, getISOString, etc.).