46

No, I'm not talking about zone offsets --- those can vary during the year for a region based on e.g. DST. I'm talking about the actual time zones maintained by IANA. I understand these are not supported by ISO 8601, correct?

What are platforms doing to support identifying time zones in ISO 8601-like string representations? I notice that the latest Java date/time library is using an extended ISO 8601 format for this, e.g. 2011-12-03T10:15:30+01:00[Europe/Paris]. (See DateTimeFormatter API.)

Is there some converging convention (e.g. with other languages and platforms) for extending ISO 8601 to support time zone designation?

Garret Wilson
  • 18,219
  • 30
  • 144
  • 272
  • The second bullet point makes this question rather broad. – chrylis -cautiouslyoptimistic- Feb 13 '17 at 00:19
  • The way I read [the W3C description](https://www.w3.org/TR/NOTE-datetime), you seem to be correct: ISO 8601 supports zone offsets, but not timezones with variable offsets (typically timezones with summer time, which goes for many of the IANA timezones). – Ole V.V. Feb 13 '17 at 00:43
  • 1
    @OleV.V. The W3C Note document you linked is but a brief synopsis of the actual ISO 8601 standard. I suggest reading the excellent [Wikipedia article on ISO 8601](https://en.wikipedia.org/wiki/ISO_8601) and on [week date](https://en.wikipedia.org/wiki/ISO_week_date), and perhaps a [draft of the standard](https://duckduckgo.com/?q=ISO+8601+draft&t=osx&ia=web) (official standard is behind a paywall). – Basil Bourque Feb 13 '17 at 05:53
  • I just want to note that I'm amazed that, at the time the bounty is expiring, all these people and all these comments could come up with _only one other example of a library/platform_ (@MattJohnson mentioned Node Time) that includes the time zone in a string format! – Garret Wilson Apr 19 '17 at 13:29

2 Answers2

36

Update:

There's now a draft IETF proposal to extend RFC3339 with the time zone identifier in square brackets, among other things: https://datatracker.ietf.org/doc/draft-ietf-sedate-datetime-extended/

Original Answer:

I understand these are not supported by ISO 8601, correct?

Correct. ISO-8601 does not concern itself with time zone identifiers. IANA/Olson TZ names are not a "standard". They are just the most reliable thing we have. (Some may consider them the de facto standard.)

What are platforms doing to support this?

Support what exactly? This part of your question is unclear. If you mean to support IANA time zones, well that's all over the place. Some platforms have them built-in, and some rely on libraries. If you mean to support a string representation of an ISO-8601 date-time-offset + time zone ID, some platforms have this and some do not. You'll have to be more specific if you want to know more.

I notice that the latest Java date/time library is using an extended ISO 8601 format for this, e.g. 2011-12-03T10:15:30+01:00[Europe/Paris]. (See DateTimeFormatter API.)

I think you are talking about DateTimeFormatter.ISO_ZONED_DATE_TIME. The docs say specifically:

The ISO-like date-time formatter...

...extends the ISO-8601 extended offset date-time format to add the time-zone. The section in square brackets is not part of the ISO-8601 standard.

So this is Java's specific format, not a standard.

Is there some converging convention (e.g. with other languages and platforms) for extending ISO 8601 to support time zone designation?

As far as I know, there is currently no standard that covers the combining of an ISO8601 timestamp and an IANA time zone identifier into a single format. One could represent it many different ways, including:

  • 2011-12-03T10:15:30+01:00[Europe/Paris] (this is the default in Java 8)
  • 2011-12-03T10:15:30+01:00(Europe/Paris)
  • 2011-12-03T10:15:30+01:00 Europe/Paris
  • 2011-12-03T10:15:30+01:00 - Europe/Paris
  • 2011-12-03T10:15:30+01:00/Europe/Paris
  • 2011-12-03T10:15:30+01:00|Europe/Paris
  • 2011-12-03T10:15:30 Europe/Paris (+01) (this is the default in Noda Time)

If what you're looking for is a way to include a ZonedDateTime or similar data in an API in a standardized manner, my personal recommendation would be to pass the time zone name in a separate field. That way, each portion of data is as good as it can be. For example in JSON:

{
  "timestamp": "2011-12-03T10:15:30+01:00",
  "timezone": "Europe/Paris"
}
Matt Johnson-Pint
  • 230,703
  • 74
  • 448
  • 575
  • Also, interestingly enough, the [Java ZonedDateTime docs](https://docs.oracle.com/javase/8/docs/api/java/time/ZonedDateTime.html) at the top use a format with a space separator instead of the brackets. ;) – Matt Johnson-Pint Feb 13 '17 at 17:26
  • 1
    "Support what exactly? This part of your question is unclear." Well, I thought I put that in the title... But fair enough---I have updated the question. "If you mean to support a string representation of an ISO-8601 date-time-offset + time zone ID, some platforms have this and some do not." Well, that's the question I'm asking. What are other platforms doing? I was hoping someone could give me some other examples, so I could know if Java was alone on this or if it is following some converging trend. – Garret Wilson Feb 14 '17 at 15:15
  • "One could represent it many different ways..." Indeed @MattJohnson, I could sit here all day inventing hundreds of possible variations for representation the time zone. The question is whether there is some emerging consensus, or even other examples of usage "in the wild" other than the Java approach. – Garret Wilson Apr 12 '17 at 13:57
  • Sure. I was just trying to illustrate that there is no emerging consensus. The last example I give up there is [the default "general" pattern from Noda Time](http://nodatime.org/2.0.x/userguide/zoneddatetime-patterns). – Matt Johnson-Pint Apr 12 '17 at 16:43
  • 1
    Also, it sounds like what you're looking for is an RFC. Perhaps you should propose one? :) – Matt Johnson-Pint Apr 12 '17 at 16:45
  • if one of the example is from Noda Time, perhaps you could update the answers to indicate this? My question wanted to find out how other languages and libraries are handling this, not just create all combinations that _could_ be created. Could you please indicate which of the formats listed are being used, and which are essentially just hypothetical possibilities? Otherwise the answer isn't that helpful, as least in regards to the actual question. – Garret Wilson Apr 17 '17 at 16:02
  • "If you mean to support a string representation of an ISO-8601 date-time-offset + time zone ID, some platforms have this and some do not." Since you know of some "platforms [that] have this", could you perhaps list those platforms and what they use? Of course you'll need to actually _identify_ those platforms or it won't help me very much. Thank you. – Garret Wilson Apr 17 '17 at 16:13
  • 3
    Hey, I just found out that [there's a draft for ISO8601-2 "extentions" in the works at ISO](https://www.iso.org/news/2017/02/Ref2164.html), and of course I immediately thought of you. Perhaps you could contact them to suggest including this? :) – Matt Johnson-Pint Apr 22 '17 at 21:17
  • 1
    FYI - I started a Twitter thread [here](https://twitter.com/mj1856/status/855896143825297408), if you'd like to chime in. :) – Matt Johnson-Pint Apr 22 '17 at 21:33
  • Wow, that is awesome, @MattJohnson. I'd love to talk to you more about how your project relates to mine. I sent you a request on LinkedIn; please contact when you have a chance. Thanks. – Garret Wilson Apr 22 '17 at 21:50
  • 1
    @GarretWilson - FYI - There's now a draft IETF proposal to extend RFC3339 with the time zone identifier in square brackets, among other things: https://github.com/ryzokuken/draft-ryzokuken-datetime-extended – Matt Johnson-Pint Jan 11 '21 at 20:47
26

The Answer by Matt Johnson is spot-on correct. I'll just add a few thoughts.

Time zone versus offset-from-UTC

An offset-from-UTC is merely a number of hours, minutes, and seconds ahead/behind UTC. Alone, this does make a date-time into a specific moment on the timeline. But it is not nearly as informative as including the official time zone name as well.

While there is no standard yet for including the time zone name, I do hope others follow the lead of the java.time classes in appending in square brackets the name of the time zone. This format seems sensible to me as it would be simple to truncate the square-bracket portion to be backward-compatible with non-savvy software.

For example:
2011-12-03T10:15:30+01:00[Europe/Paris]. If the data were only 2011-12-03T10:15:30+01:00, we would be able to identify the moment on the timeline, but would not be able to adjust other moments into the same frame of mind as we would not know what rules of adjustment to apply. Zones such as Europe/Zagreb, Africa/Brazzaville, Arctic/Longyearbyen, and Europe/Isle_of_Man all share the offset of +01:00, but they may well have other adjustments in force differing from those of Europe/Paris. So if you were to try to add three days to the value 2011-12-03T10:15:30+01:00, you really cannot faithfully compute the result because you do not know what adjustments may need to apply such as DST cutovers that may be occurring during those three days.

A time zone defines the set of rules for handling anomalies such as Daylight Saving Time (DST). Politicians around the world enjoy making adjustments to their time zones, or even re-defining them. So these rules change frequently. Think of a time zone as a collection of offsets over time, many periods of time in history wherein each period had a particular offset in use in that particular region.

You can think of a time zone as a collection of offset-from-UTC values. In America/Los_Angeles part of this year is 8 hours behind UTC, and part of the year will be 7 hours behind UTC. That makes 2 points of data collected as part of that time zone.

Another example, in previous years, Turkey spent part of each year 2 hours ahead of UTC and part of each year 3 hours ahead. In 2016, that changed to indefinitely staying 3 hours ahead. So, multiple points of data in the time zone Europe/Istanbul.

Just use UTC

Personally I do not see much value in even using values such as 2011-12-03T10:15:30+01:00. Without a time zone, you might just as well use UTC alone. In this case, 2011-12-03T09:15:30Z (9 AM instead of 10 AM).

Generally the best practice is to use UTC when storing and exchanging date-time values. Think of UTC as the One-True-Time, with zoned or offset values being mere variations.

Bastien
  • 635
  • 5
  • 16
Basil Bourque
  • 303,325
  • 100
  • 852
  • 1,154
  • 2
    Agree in general with advice to use UTC, where possible. Some use cases are awkward, however: if logic must refer to an arbitrary event in the past or future for which the only time info is in the local zone, then the UTC conversion is not obvious. (For example, what time will the NYSE open on the second Tuesday in March, 10 years from now? In local time, it's most likely 9:30am ET, but UTC depends on DST conversion -- and even that is contingent on the rules not changing before then.) So in such cases, it would be preferable to have a standard for representing locally-zoned times. – sumitsu Apr 13 '17 at 19:50
  • 1
    @Sumitsu I agree completely, 100%. I emphasize the opposite position because I find programmers tend to (a) drive themselves nuts converting in and out of their own parochial time zone, and (b) think (pray?) that use of “local” (unzoned) date-time values will somehow free them from having to deal with time zone issues. But as you say, `LocalDateTime` is certainly useful in many situations, especially appts like NYSE opening, because politicians so often, so carelessly, & so quickly redefine time zones. Just last year, for example, Turkey decided to stay on DST with only several weeks warning. – Basil Bourque Apr 14 '17 at 20:18
  • Just the TZ-offset allows collecting *some* client-relative value. While not nearly as robust as TZ names for other purposes, it does provide a small step.. mainly (for, in 99% of cases, at *time of recording*) allowing a "day" as distinct from a time while capturing both within a 'single scalar'. A TZ-offset does have the nice property over a TZ name in that it is a pure mapping to UTC, although being able to *also* capture the TZ name in such a 'single scalar' form would be nice to enable future improved handling :} – user2864740 Mar 05 '18 at 19:23
  • ..and the pure concept of a "day" is often missed with UTC-only time approaches. Yet, for many aspects of living, all that is relevant is the day and relative time.. and in this common context it doesn't matter if this day jumps forwards and back from 'real time' through the year(s). – user2864740 Mar 05 '18 at 19:30