UTC vs ISO format for time

Question

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?

Mosa

Are you asking what's the purpose of UTC? Or are you asking what's the purpose of the JavaScript Date object's toUTCString function? – Petaliferous

You'd use toISOString for sharing a date with another machine and toUTCString if you want an especially ugly, locale insensitive way of displaying dates to a human. – Gherardo

Answer 1

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.

(photo source)

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.

Gleet

Thanks a lot for your feedback. Taking the first example 2019-11-14T00:55:31.820Z how do I know which time zone this falls onto? is it the 820Z value? – Mosa

As mentioned in my Answer, the Z on the end means UTC (an offset of zero), and is pronounced “Zulu”. So not a time zone, just a mere offset-from-UTC. A time zone has name Continent/Region, and is a history of past, present, and future changes to the offset used by the people of a particular region. – Gleet

Ok, I'm a bit confused now, when you say UTC (an offset of zero) how is this related to the ISO format? – Mosa

@tmpdev Do you understand formats have to do with text, with strings? "ISO" and "UTC" are not formats. The Z on the end of 2019-11-14T00:55:31.820Z means the time of fifty-five minutes after midnight when staring at the official clock outside the Royal Observatory in Greenwich, London on the prime meridian (and also the time seen on all clocks in Iceland which uses UTC as their time zone). Without the Z we would would not know if this meant nearly 1 AM in Tokyo Japan, 1 AM in Paris France, or 1 AM in Toledo Ohio US — which are very different moments, happening several hours apart. – Gleet

Thanks for this clarification, its much clearer now. – Mosa

Thanks very much. I finally understand that the Z means the meridian. ISO8601 as explained on Wikipedia is awful btw. It is massively confusing IMO. What I would REALLY like, is for someone to make a link between ISO8601 and UTC 8601 in a clear and concise way saying that the representational i.e. the format, of ISO8601 lends itself very nicely to the UTC time-keeping methodology...it makes it unambiguous. If you have a Z at the end of the ISO8601, you know it is representing a dateTime with a zero offset...but the Z stands for Zulu not zero...it could be used as a rule of thumb. – Chauvin

@Chauvin The use of Z comes from traditions in aviation and the military, predating ISO 8601. The Z does indeed stand for zero, with that letter being pronounced “Zulu” in those traditions. See NATO phonetic alphabet. – Gleet

Re: "Generally best to do most of your thinking, business logic, data storage, data exchange, and logging in UTC." Counterargument (to homogenizing timestamps to Z vs representing timestamps in the original local time of the event, with the corresponding zone designator): one could argue that you're losing data. You can no longer answer the questions: From which time zone did this data originate? What was the local time of this event? And that can be useful information. Thoughts on that? – Transpolar

@GrahamHannington If your business problem scenario is such that you care about the time zone of an original input, then you should record that fact specifically. For example, most databases do not store the time zone in a column of a type akin to the SQL standard type TIMESTAMP WITH TIME ZONE — they adjust inputs to UTC before storing, then discard the time zone or offset info. So if you care, add another column to record the name of the time zone. – Gleet

@GrahamHannington As for knowing the local time of that event, easy-peasy: Instant.parse( "2019-11-14T00:55:31.820Z" ).atZone( ZoneId.of( "Asia/Tokyo" ) ).toString() produces: 2019-11-14T09:55:31.820+09:00[Asia/Tokyo] – Gleet

Answer 2

I'm using <p-calendar> V.8.2.9 LTS. The selected Date in <p-calendar> returned in the legacy format of RFC like Thu Apr 01 2021 00:00:00 GMT-0400 (Eastern Daylight Time). I had to convert RFC to ISO string.

I simply followed this thread and this article, used JSON.stringify() to wrap around the variable that returns RFC format.

for example:

console.log(date); // Wed Jan 01 2014 13:28:56 GMT-1000 (Hawaiian Standard Time) 
        
var json = JSON.stringify(date);
console.log(json);  // "2014-01-01T23:28:56.782Z"

Network