I am formatting a given date using momentjs. The following behaves differently in different timezones:
moment(new Date("2016" + "-" + "06" + "-01").toISOString()).format('MMMM YYYY')
It gives me May 2016 in timezone of America/Denver and June 2016 in Asia/Karachi. I tested by changing the browser timezone to different timezones. It should be June 2016 in both.
When i change the format in new Date() to use slashes instead of hyphens like below, it gives me correct result in both timezones i.e. May 2016.
moment(new Date("2016" + "/" + "06" + "/01").toISOString()).format('MMMM YYYY')
Both seem to be valid ISO strings, what would cause this inconsistency?
The short answer to your question is that parser for javascript date doesn't work in a way that makes sense to anybody. Instead, you should just use Moment's parser to get the result you want. Parsing dates in a way that makes sense is about 50% of the reason that moment exists.
If you eliminate the date call and use Moment to parse your date, you will observe that the following code will result in June 2016 in any browser, because your string will be interpreted as local time if you are using Moment's default constructor:
moment('2016-06-01').format()
If you wanted to use slashes instead, it would be:
moment('2016/06/01', 'YYYY/MM/DD').format()
See moment's parsing guide for more information about how moment interprets times with it's different constructor methods.
The long answer is that when you pass a string in ISO8601 format that is date only to the JavaScript date constructor, it will interpret that string as UTC. Because Denver is UTC -6 on daylight time, and Karachi is UTC +5 all the time, when moment then displays that timestamp as local time you see the result that you do. You can observe the following:
var a = new Date('2016-06-01');
a.toISOString();
"2016-06-01T00:00:00.000Z"
Note that the 'Z' in the above timestamp indicates that it is UTC, as toISOString always returns a UTC timestamp. That timestamp is June in Karachi because Karachi is ahead of UTC, while May in Denver because Denver is behind UTC.
Observe this as well:
var a = new Date('2016-06-01T00:00');
a.toISOString();
"2016-06-01T05:00:00.000Z"
If I put a time on my string, it is interpreted as local time. Because my timezone was UTC-5 on January 1, the point on the global timeline is appropriately five hours ahead of the string I passed.
The behavior you are seeing - interpreting 2016-06-01 as UTC, but 2016-06-01T00:00 as local, is actually an effort to accommodate technical debt across browsers. It has been made the standard behavior in the 7th edition of the ECMA 262 specification, so expect for that not to change. See this link as well.
Alternately, when you use the slashes (2016/06/01) the JS implementation that you are using is choosing to interpret that format as local time, as it does not conform to any of the formats in the ECMA standard. This is NOT a valid ISO8601 format. It is very important to note that this behavior is implementation specific, and will vary across browsers/environments. The ECMA standard does not define a behavior for parsing that date format. Other browsers may parse this string in other ways.
As general advice, don't use the JavaScript date parser. It doesn't work right. You can use Moment.js, one of moment's several competitors, or manually parse strings yourself. All of these are better options.
Related
When using new Date or Date.parse in JavaScript, I cannot just pass arbitrary date formats. Depending on the format, I get a different date than I wanted to or even Invalid Date instead of a date object. Some date formats work in one browser but not in others. So which date time formats should I use?
Additional questions:
Do all browsers support the same formats? How do Mozilla Firefox, Google Chrome, Microsoft Internet Explorer, Microsoft Edge, and Apple Safari handle date time strings? What about Node.js?
Does it take the local date format into consideration? E.g. if I live in Switzerland and the date format is 30.07.2018, can I use new Date('30.07.2018')?
Does it take the local time zone into consideration?
How can I get a date time string from a date object?
How can I detect invalid date time strings?
How do date libraries like Moment.js handle date strings?
In case you did not notice, I answered my own question (why?).
The Essentials
JavaScript officially supports a simplification of the ISO 8601 Extended Format. The format is as follows: YYYY-MM-DDTHH:mm:ss.sssZ. The letter T is the date/time separator and Z is the time zone offset specified as Z (for UTC) or either + or - followed by a time expression HH:mm.
Some parts (e.g. the time) of that format can be omitted.
Note that years must have at least four digits, month/day/hours/minutes/seconds must have exactly two digits, and milliseconds must have exactly three digits. For example, 99-1-1 is not a valid date string.
These are some examples of valid date (time) strings:
2018-12-30
2018-12-30T20:59
2018-12-30T20:59:00
2018-12-30T20:59:00.000Z
2018-12-30T20:59:00.000+01:00
2018-12-30T20:59:00.000-01:00
When you omit the time zone offset, date-times are interpreted as user local time.
When you omit the time altogether, dates are interpreted as UTC.
Important:
All modern and reasonably old browsers and implementations support the full-length date time format according to the specification.
However, there are differences in the handling of date (time) strings without a time zone (see "Missing Time Zone Offset" below for details). You should not use date time strings without a time zone (Status 2018).
Instead pass a unix timestamp in milliseconds or separate arguments for different parts of the date to the Date constructor.
Most browser also support some other formats but they are not specified and thus don't work in all browsers the same way.
If at all, you should only use the date time string formats explained above.
Every other format might break in other browsers or even in other versions of the same browser.
If you run into Invalid Date instead of a date object, you most probably are using an invalid date time string.
And now with a little more detail.
Date Time String Format
ECMAScript (the specification that the JavaScript language implements) has been supporting date strings in new Date (specification) and Date.parse (specification) since its inception.
However, the first versions did not actually specify a date time format.
This changed in 2009 when ES5 was introduced with a specification of a date time format.
The Basics
ECMAScript specifies the Date Time String Format as a simplification of the ISO 8601 Extended Format. The format is as follows: YYYY-MM-DDTHH:mm:ss.sssZ.
YYYY is the decimal digits of the year 0000 to 9999 in the proleptic Gregorian calendar.
- (hyphen) appears literally twice in the string.
MM is the month of the year from 01 (January) to 12 (December).
DD is the day of the month from 01 to 31.
T appears literally in the string, to indicate the beginning of the time element.
HH is the number of complete hours that have passed since midnight as two decimal digits from 00 to 24.
: (colon) appears literally twice in the string.
mm is the number of complete minutes since the start of the hour as two decimal digits from 00 to 59.
ss is the number of complete seconds since the start of the minute as two decimal digits from 00 to 59.
. (dot) appears literally in the string.
sss is the number of complete milliseconds since the start of the second as three decimal digits.
Z is the time zone offset specified as "Z" (for UTC) or either "+" or "-" followed by a time expression HH:mm
The specification also mentions that if "the String does not conform to [the specified] format the function may fall back to any implementation-specific heuristics or implementation-specific date formats" which might result in different dates in different browsers.
ECMAScript does not take any user local date time formats into account which means that you can not use country or region-specific date time formats.
Short Date (and Time) Forms
The specification also includes shorter formats as follows.
This format includes date-only forms:
YYYY
YYYY-MM
YYYY-MM-DD
It also includes “date-time” forms that consist of one of the above date-only forms immediately followed by one of the following time forms with an optional time zone offset appended:
THH:mm
THH:mm:ss
THH:mm:ss.sss
Fallback Values
[...] If the MM or DD fields are absent "01" is used as the value. If the HH, mm, or ss fields are absent "00" is used as the value and the value of an absent sss field is "000". When the time zone offset is absent, date-only forms are interpreted as a UTC time and date-time forms are interpreted as a local time.
See "Missing Time Zone Offset" below for more information on the lacking browser support.
Out of Bound Values
Illegal values (out-of-bounds as well as syntax errors) in a format string means that the format string is not a valid instance of this format.
For example, new Date('2018-01-32') and new Date('2018-02-29') will result in a Invalid Date.
Extended Years
The date time format of ECMAScript also specifies extended years which are six digit year values.
An example of such an extended year string format looks like +287396-10-12T08:59:00.992Z which denotes a date in the year 287396 A.D.
Extended years can either be positive or negative.
Date API
ECMAScript specifies a wide range of date object properties.
Given a valid date object, you can use Date.prototype.toISOString() to get a valid date time string.
Note that the time zone is always UTC.
new Date().toISOString() // "2018-08-05T20:19:50.905Z"
It is also possible to detect whether a date object valid or an Invalid Date using the following function.
function isValidDate(d) {
return d instanceof Date && !isNaN(d);
}
Source and more information can be found in Detecting an “invalid date” Date instance in JavaScript.
Examples
Valid Date Time Formats
The following date time formats are all valid according to the specification and should work in every browser, Node.js or other implementation that supports ES2016 or higher.
2018
2018-01
2018-01-01
2018-01-01T00:00
2018-01-01T00:00:00
2018-01-01T00:00:00.000
2018-01-01T00:00:00.000Z
2018-01-01T00:00:00.000+01:00
2018-01-01T00:00:00.000-01:00
+002018-01-01T00:00:00.000+01:00
Invalid Date Time Formats
Note that the following examples are invalid as per the specification.
However, that does not mean that no browser or other implementation interprets them to a date. Please do not use any of the date time formats below as they are non-standard and might fail in some browsers or browser versions.
2018-1-1 // month and date must be two digits
2018-01-01T0:0:0.0 // hour/minute/second must be two digits, millisecond must be three digits
2018-01-01 00:00 // whitespace must be "T" instead
2018-01-01T00 // shortest time part must have format HH:mm
2018-01-01T00:00:00.000+01 // time zone must have format HH:mm
Browser Support
Today, every modern and reasonably old browser supports the date time format that was introduced with the ES5 specification in 2009.
However, even today (Status 2018) there are different implementations for date time strings without a time zone (see "Missing Time Zone Offset" below).
If you need to support older browsers or use strings without a time zone, you should not use date time strings.
Instead, pass a number of milliseconds since January 1, 1970, 00:00:00 UTC
or two or more arguments representing the different date parts to the Date constructor.
Missing Time Zone Offset
ES5.1 incorrectly states that the value of an absent time zone offset is “Z” which contradicts with ISO 8601.
This mistake was fixed in ES6 (ES2015) and extended on in ES2016 (see "Changes to the ECMAScript Specifications" below).
As of ES2016, date time strings without a time zone are parsed as local time while date only strings are parsed as UTC.
According to this answer, some implementations never implemented the behaviour specified in ES5.1.
One of them seems to be Mozilla Firefox.
Other browsers that seem to be compliant with the specification of ES2016 (and higher) are Google Chrome 65+, Microsoft Internet Explorer 11, and Microsoft Edge.
The current version of Apple Safari (11.1.2) is not compliant as it erroneously parses date time strings without a time zone (e.g. 2018-01-01T00:00) as UTC instead of local time.
Legacy Date Time Formats
ES5 introduced a specification for date time strings in 2009.
Before that, there were no specified formats that were supported by all browsers.
As a result, each browser vendor added support for different formats which often did not work accross different browsers (and versions).
For a small example of ancient history, see date-formats.
Most browsers still support those legacy formats in order to not break the backward compatibility of older websites.
But it is not safe to rely on those non-standard formats as they might be inconsistent or get removed at any time.
Date.prototype.toString() and Date.prototype.toUTCString()
ES2018 for the first time specified the date format that is returned by Date.prototype.toString() and Date.prototype.toUTCString().
Already before that, the ECMA Specification required the Date constructor and Date.parse to correctly parse the formats returned by those methods (even though it did not specify a format before 2018).
An example return value of Date.prototype.toString() may look like this:
Sun Feb 03 2019 14:27:49 GMT+0100 (Central European Standard Time)
Note that the timezone name within brackets is optional and the exact name is "implementation-dependent".
Date.prototype.toUTCString() returns a date in a similar format as Date.prototype.toString() but with a zero timezone offset. An example format may look like this:
Sun, 03 Feb 2019 13:27:49 GMT
Note that there is a comma , after the weekday and day month are reversed compared to Date.prototype.toString().
As those formats have only been specified in 2018, you should not rely on them working equally in different implementations (especially older browsers).
Node.js
Node.js is running on the V8 JavaScript engine which is also used in Google Chrome.
So the same specification regarding the date time string format applies.
As the code runs in the backend though, the user local time does not influence the time zones but only the settings on the server do.
Most platform as a service (PaaS) provider that host Node.js applications use UTC as their default time zone.
Date Time Libraries
Moment.js
Moment.js is a very popular library to help with the handling of dates in JavaScript and it also supports more formats than ECMAScript specifies.
In addition, Moment.js also supports creating date objects based on a string and a arbitrary format.
Luxon
Luxon supports parsing of ISO 8601, HTTP, RFC2822, SQL, and arbitrary formats. But only using different functions for different date time formats.
Changes to the ECMAScript Specifications
A list of notable changes in the ECMAScript specifications regarding date time string formats.
Changes in ES2018
Introduces a specification for the date formats returned by Date.prototype.toString() and Date.prototype.toUTCString().
Changes in ES2017
No notable changes.
Changes in ES2016
If the time zone offset is absent, the date-time is interpreted as a local time.
When the time zone offset is absent, date-only forms are interpreted as a UTC time and date-time forms are interpreted as a local time.
Changes in ES6 (ES2015)
The value of an absent time zone offset is “Z”.
If the time zone offset is absent, the date-time is interpreted as a local time.
From Corrections and Clarifications in ECMAScript 2015 with Possible Compatibility Impact:
If a time zone offset is not present, the local time zone is used. Edition 5.1 incorrectly stated that a missing time zone should be interpreted as "z".
See Date Time String Format: default time zone difference from ES5 not web-compatible for more details on that change.
Changes in ES5.1
If the MM or DD fields are absent “01” is used as the value. If the HH, mm, or ss fields are absent “00” is used as the value and the value of an absent sss field is “000”. The value of an absent time zone offset is “Z”.
Changes in ES5
First introduction of a date time string format to the ECMAScript specification.
ECMAScript defines a string interchange format for date-times based upon a simplification of the ISO 8601 Extended Format. The format is as follows: YYYY-MM-DDTHH:mm:ss.sssZ
Also introduces Date.prototype.toISOString() which returns a date time string in that specified format.
Changes in ES3
Deprecates Date.prototype.toGMTString() and replaces it with Date.parse(x.toUTCString()) in the section mentioning that the format returned by these methods must be correctly parseable by implmentations of Date.parse. Note that the format returned by Date.parse(x.toUTCString()) is "implementation-dependent".
Changes in ES2
No notable changes.
Initial Specification: ES1
ES1 introduced date time strings to be used in new Date(value) and Date.parse(value).
However, it did not specify an actual date (time) format, it even states that
[...] the value produced by Date.parse is implementation dependent [...]
The specification also mentions that
If x is any Date object [...], then all of the following expressions should produce the same numeric value in that implementation [...]:
[...]
Date.parse(x.toString())
Date.parse(x.toGMTString())
However, the returned value of both Date.prototype.toString() and Date.prototype.toGMTString() were specified as "implementation dependent".
So which date time formats should I use?
The general recommendation is to not use the built-in parser at all as it's unreliable, so the answer to "should" is "none". See Why does Date.parse give incorrect results?
However, as str says, you can likely use the format specified in ECMA-262 with a timezone: YYYY-MM-DDTHH:mm:ss.sssZ or YYYY-MM-DDTHH:mm:ss.sss±HH:mm, don't trust any other format.
Do all browser support the same formats?
No.
How do Mozilla Firefox, Google Chrome, Microsoft Internet Explorer, Microsoft Edge, and Apple Safari handle date time strings?
Differently. Anything other than the format in ECMA-262 is implementation dependent, and there are bugs in parsing the the ECMA-262 format.
What about Node.js?
Likely different again, see above.
Does it take the local date format into consideration? E.g. if I live in Switzerland and the date format is 30.07.2018, can I use new Date('30.07.2018')?
Maybe. Since it's not the standard format, parsing is implementation dependent, so maybe, maybe not.
Does it take the local time zone into consideration?
It uses the host timezone offset where the string is parsed as local and to generate the string displayed using local times. Otherwise it uses UTC (and the internal time value is UTC).
How can I get a date time string from a date object?
Date.parse.toString, or see Where can I find documentation on formatting a date in JavaScript?
How can I detect invalid date time strings?
One of the first 3 answers here should answer that.
How do date libraries like Moment.js handle date strings?
They parse them based on either a default or provided format. Read the source (e.g. fecha.js is a simple parser and formatter with well written, easy to follow code).
A parser isn't hard to write, but trying to guess the input format (as built-in parsers tend to do) is fraught, unreliable and inconsistent across implementations. So the parser should require the format to be provided unless the input string is in the parser's default format.
PS
There are changes to the formats of strings that implementations must support for parsing and formatting in ECMAScript 2019 (currently in draft), but I think the general advice to avoid the built–in parser will stand for some time yet.
I have an ejs file displaying a date that is coming from my node server and mongoose database. In the server and database, the date is correct, I set a console.log for the date, and it returns:
2020-06-10T00:00:00.000Z
June 10th, as expected. However, when I have it display in the ejs file, it displays as June 9th:
<p><%= ticket.due_date.toDateString() %></p>
and it displays on the page as
Tue Jun 09 2020
This also seems to be a problem when I use moment to refactor the date format for sending to the ejs file:
console.log(ticket.due_date);
date = moment(ticket.due_date).format("YYYY-MM-DD");
console.log(date);
and this outputs into the console as:
2020-06-10T00:00:00.000Z
2020-06-09
Is there some formatting issue I am missing, or is it inherent with the system and if so, how do I simply add a day in the ejs file to make it correct? Thank you.
A Date is not a string; it's an object that encapsulates a moment in time (internally, a big number). It doesn't carry any other interesting details like how the string you used to create it was originally formatted. So when you output a Date with .toDateString(), will simply output a string for the timestamp according to the JavaScript spec for .toDateString().
There are numerous valid ways to format a Date as a string. I'd look through the docs on Date. For example, one option is .toISOString() which seems to be the format you're expecting. If you want to output user-friendly dates in a multitude of formats, you'll need to look to libraries like Moment.js.
Update:
You seem to be working with a misconception about dates. An ISO 8601 date like the example 2020-06-10T00:00:00.000Z means midnight UTC (a.k.a. GMT, Zulu, etc). a Date doesn't represent a local calendar date, it represents a moment in time, specifically the number of milliseconds since 1 January, 1970, UTC. This means when you deal with JavaScript dates, you should be intentional to construct them with the appropriate understanding that they represent a moment in time. For example, if you want a date to reflect midnight in your local time zone, you can use the constructor:
const date = new Date(2020, 5, 10);
...and when you output the date, you should remember that the person viewing the moment in time may be in a different time zone, so the date may not reflect as the exact same thing.
If you're wanting to deal with a calendar date instead of a timestamp (which would have been a better name for Date), then you can use UTC dates throughout and make sure when you output strings that you specify you want to format the date using the UTC time offset. Alternately, you might want to stick with strings if you don't want any of the semantics of timestamps.
My local time zone is (UTC+06:00) Dhaka. In my own time zone I didn't find this problem. But changing the time zone to (UTC -12:00) International Date Line West in my pc,
new Date(["2014","01","01"]) is giving me output Wed Jan 01 2014 00:00:00 GMT-1200 (GMT-12:00).
new Date("2014-01-01") is giving me output Tue Dec 31 2013 12:00:00 GMT-1200 (GMT-12:00).
Why this is happening?
Shouldn't ["2014","01","01"] and "2014-01-01" suppose to give same output?
This is due to new Date("2014-01-01") being created through the Date parse which considers this date to be UTC and then apply the timezone but new Date(["2014","01","01"]) is treated as literal values for each of the parameters in the constructor for your timezone. Although as mentioned in one of the comments below the format new Date(["2014","01","01"]) does not conform to RFC and hence provides different results depending on the browser.
from: https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Date
Note: Parsing of date strings with the Date constructor (and Date.parse(), which works the same way) is strongly discouraged due to browser differences and inconsistencies. Support for RFC 2822 format strings is by convention only. Support for ISO 8601 formats differs in that date-only strings (e.g. "1970-01-01") are treated as UTC, not local.
Perhaps what you are after is new Date(Date.UTC(2014,01,01)); Date.UTC in order to create a consistent date that is not bound to the user's configuration.
A few things:
The Date constructor does not accept an array. See the specification, and the MDN docs. Any such allowance is implementation-specific. For example, new Date(["2014","01","01"]) will work in Chrome because the Chrome authors decided to allow it, but in Edge it gives an Invalid Date because it is not required by the specification. (The same applies to Date.UTC(array).)
If you have separate date parts, you should pass them directly into the constructor. Note that in this form of the constructor, the months range from 0 to 11, so you must subtract one from the second parameter.
new Date(2014, 0, 1)
When you use the above form, the parameters are intended to be in terms of local time - that is, the time zone that is set for the environment where the code executes (the user's time zone in a browser environment, or the server's time zone in a Node.js environment). The time parameters (hour, minute, second, millisecond) default to 0, so this is midnight in the local time zone, or 2014-01-01T00:00:00.000.
If you intended to pass UTC-based parameters, use the Date.UTC function, and pass the result back to the Date constructor, as in:
new Date(Date.UTC(2014, 0, 1))
This sets the date object to midnight UTC, or 2014-01-01T00:00:00.000Z.
When you pass a string to the date constructor, it is first attempted to be parsed according to rules defined in the specification. If it cannot be parsed by the specification's rules, then it may be parsed in an implementation-specific manner.
The specification defines that a string in YYYY-MM-DD format (without any time portion) is to be parsed as UTC. This deviates from ISO-8601, and is why you are seeing different results when you call new Date("2014-01-01"). It is interpreted as if you passed 2014-01-01T00:00:00.000Z (UTC).
The Date object itself tracks only one single value, which is the number of milliseconds since the Unix epoch, which is 1970-01-01T00:00:00.000Z (UTC). You can see this value by calling .valueOf() or .getTime(). Thus when you parse with any form that is treated as local time, then a conversion happens at the time of parsing, from local time to UTC.
Later, when you do anything that expects local time output, such as calling .toString(), or using functions like .getDate(), .getHours(), etc., another conversion from the internal UTC-based timestamp to local time is performed.
In some environments, you will also see the conversion happen when you console.log a Date object, as if you called .toString(). In others, you will see the UTC-based output as if you called .toISOString(). The console output is implementation-specific.
Notice that GMT time is -1200. When you are specifying the date, I believe it starts at midnight of that day. Since you stated 2014-01-01, it subtracted 12 hours from midnight on that day, giving you 2013-12-31 at 12:00PM.
This is javaScript code, new Date() returns invalid value.
Do I need change the date format before pass it to new Date()?
new Date("25-Feb-17");
On MDN, you can read the following about this particular Date constructor:
Note: parsing of date strings with the Date constructor (and Date.parse, they are equivalent) is strongly discouraged due to browser differences and inconsistencies. Support for RFC 2822 format strings is by convention only. Support for ISO 8601 formats differs in that date-only strings (e.g. "1970-01-01") are treated as UTC, not local.
If you want the constructor to work correctly across all browsers, either use one of its other variants (also described on the linked MDN page) or at least reformat your date string to be compliant with the ISO8601 date representation. The latter option isn't 100% guaranteed to work though since JavaScript uses a slightly simplified convention for representing dates as strings; you might find corner cases that will fail.
Also, as per the quoted note, there's a caveat. Using simplified date formats such as "2017-02-25" will be treated as UTC, but then internally translated to your local timezone. Assuming you're on the western hemisphere, the final result will be February 24th instead.
Its not working on Firefox, tested on Chrome and worked fine so I suggest you to use the standard Date object creation as follows:
new Date(year, month, day, hours, minutes, seconds, milliseconds)
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.
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.
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()
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.