UTC vs ISO format for time
I'm trying to understand the difference between UTC and ISO formats and when to use what when transferring messages between servers. So When I try the following this is what I get
new Date().toISOString()
"2019-11-14T00:55:31.820Z"
new Date().toUTCString()
"Thu, 14 Nov 2019 00:55:16 GMT"
I understand the ISO format and its a standard used to represent time, but what is the purpose of UTC and where would I use them?
Answer
tl;dr
- Always use ISO 8601 format:
2019-11-14T00:55:31.820Z - Avoid the legacy format of RFC 1123 & 822:
Thu, 14 Nov 2019 00:55:16 GMT
UTC & GMT are time-keeping, not formats
UTC and GMT are not formats.
UTC and GMT are two slightly different ways of tracking time. This is a complicated topic, so see the Wikipedia pages for the gory details if you really want to know.
For common business apps, there is no significant difference, literally less than a second’s difference. Most programmers can use the terms interchangeably. If you work for NASA, or the GPS/Galileo navigation projects, then you’ll want to learn more.
ISO 8601
The format seen in your first example 2019-11-14T00:55:31.820Z is defined by the ISO 8601 standard. The T in the middle separates the year-month-day portion from the hour-minute-second portion. The Z on the end means UTC, that is, an offset-from-UTC of zero hours-minutes-seconds. The Z is pronounced "Zulu" per military/aviation tradition.
The ISO 8601 standard is more modern. The formats are wisely designed to be easy to parse by machine as well as easy to read by humans across cultures.
Always choose ISO 8601 when serializing date-time values as text.
RFC 1123 / RFC 822
Your second example string Thu, 14 Nov 2019 00:55:16 GMT is defined in the older standards RFC 1123 & RFC 822.
These are legacy formats. They are terrible, difficult to parse by machine. And they are bad for humans as they assume English language and particular cultural norms.
Avoid this format whenever possible. Use this only when required for old protocols and systems not yet updated for ISO 8601.
Time zones
Your example of 2019-11-14T00:55:31.820Z means an offset from UTC of zero hours-minutes seconds. This is the time-of-day and date seen when standing before the clock displayed at the Royal Observatory Greenwich.
That same simultaneous moment as seen on the clocks hanging on the wall in Tunisia show an hour later: 2019-11-14T01:55:31.820+01:00[Africa/Tunis]. The time zone of Tunisia Africa/Tunis is one hour ahead of UTC at that moment, as noted by the +01:00.
That same simultaneous moment as seen on the clocks hanging on the walls in Québec show nearly 8 PM of the prior date: 2019-11-13T19:55:31.820-05:00[America/Montreal]. The time zone of Québec America/Montreal is five hours behind UTC at that moment, as noted by the -05:00.
You can see these calculations being made with Java code (not JavaScript as tagged on your Question) running live at IdeOne.com.
Generally best to do most of your thinking, business logic, data storage, data exchange, and logging in UTC. Adjust to a time zone only when required by business rules, and when presenting values to a user.