What's the difference between datetime in ISO 8601 and UTC formats in javascript?

Question

I pick some date and time in javascript and then want to store it on server (.NET). Dates are supposed to be in future from the current moment (so they won't be before 1970). Having read topics here on SO I learnt it's better to store date as a string and people suggest using Date.prototype.toISOString() or Date.prototype.toUTCString(). I've read that toISOString() is not available in IE 7. And I'd like to know other differences, when I should choose one or another function.

Answer 1

They're for different purposes.

• UTC is the primary time standard by which the world regulates clocks and time.
• ISO is standard format time. ISO also supports ms in its format.

So if you want to send data to the server, send the ISO, because ISO is the standard format:

var date = new Date();
sendDate(date.toISOString());

You can also use toISOString in IE7 polyfill.

Answer 2

I hope it will helpful to you.

Summary About toISOString() :-

The toISOString() method returns a string in ISO format (ISO 8601 Extended Format), which can be described as follows: YYYY-MM-DDTHH:mm:ss.sssZ. The timezone is always UTC as denoted by the suffix "Z".

Refer Below link for more information about toISOString().

Date.prototype.toISOString()

Summary About toUTCString() :-

The toUTCString() method converts a date to a string, using the UTC time zone.

Refer Below link for more information about toUTCString()

Date.prototype.toUTCString()

Answer 3

Always use .toISOString()

They give almost the same information, but in different formats. Here is what I get on my machine.

new Date().toISOString()
"2019-10-11T18:56:08.984Z"

new Date().toUTCString()
"Fri, 11 Oct 2019 18:56:08 GMT"

There are 4 reasons .toISOString() is more often what you want than .toUTCString().

A. More convenient sorting

When you sort alphabetically, the "2019-10-11T18:56:08.984Z" pattern of .toISOString() gives you the correct date order.

B. Millisecond precision

.toISOString() provides millisecond values, whereas .toUTCString() does not.

C. Any user can interpret correctly

The .toUTCString() value may be more familiar to human end-users, but only if the language settings are suitable for them. In contrast, the .toISOString() is the same regardless of language settings.

D. Reproducibly regeneratable by software

You can easily convert the ISO date string to a Javascript Date object, and then back again, regenerating exactly the same string. This is regardless of who gave you the ISO date string, where the server is, and where you are.

This is not automatically true for the UTC string. For example, if a second instance of your app system is running in a different time zone, or language, it's .toUTCstring() may use different numbers or words (respectively) to represent the same instant in time. It will be difficult for it to create a UTCString that matches what was made by the first instance of the app, since in general it will not know the language or timezone in which the first UTC string was produced.

I think nobody needs .toUTCString()

I don't know why `.toUTCString()` exists. Its word-heavy format makes it useless for internal storage of dates in your program, because it varies depending on your language and timezone setting etc.

So maybe it is to produce something nice to display externally for the user to see? Well, not really. Anyone who is not in the London time zone will not find it very helpful.

I live in London. And even I, even if I was writing an app purely for use by me, solely on my system, and only in my home, would still not want to use .toUTCString(). Because it is showing UTC (also known as GMT). London is not always on GMT. In summer, we move to GMT+1, so the .toUTCString() result would mislead anyone who didn't notice the "GMT" and do the time adjustment in their head.

If I wanted a natural-language time, to make non-computer literate users comfortable, I would construct it manually from parts, using a library like moment.js. If I wanted a quick-and-dirty solution, I would use .toString() which at least will move to Summer time when appropriate.