Ответ 1

Я понимаю, что они не поддерживаются ISO 8601, правильно?

Правильно. ISO-8601 не относится к идентификаторам часовых поясов. ИАНА/Олсон ТЗ имена не являются "стандартными". Они просто самые надежные вещи, которые у нас есть. (Некоторые из них могут считать их стандартом де-факто.)

Что такое платформы для поддержки этого?

Что именно? Эта часть вашего вопроса неясна. Если вы хотите поддержать часовые пояса IANA, хорошо, что повсюду. На некоторых платформах они встроены, а некоторые полагаются на библиотеки. Если вы хотите поддержать строковое представление ISO-8601 с датой и временем + ID зоны, некоторые платформы имеют это, а некоторые нет. Вы должны быть более конкретными, если хотите узнать больше.

Я заметил, что последняя Java-дата/время библиотеки использует расширенный формат ISO 8601 для этого, например. 2011-12-03T10: 15: 30 + 01: 00 [Европа/Париж]. (См. API DateTimeFormatter.)

Я думаю, вы говорите DateTimeFormatter.ISO_ZONED_DATE_TIME. Документы говорят конкретно:

Формат даты и времени, соответствующий формату ISO- ,...

... расширяет формат даты и времени расширенного формата ISO-8601, чтобы добавить временную зону. Раздел в квадратных скобках не входит в стандарт ISO-8601.

Итак, это конкретный формат Java, а не стандарт.

Существует ли соглашение о сближении (например, с другими языками и платформами) для расширения ISO 8601 для поддержки обозначения часового пояса?

Насколько я знаю, в настоящее время нет стандарта, который охватывает объединение метки времени ISO8601 и идентификатора часового пояса IANA в один формат. Можно было бы представить его разными способами, в том числе:

• 2011-12-03T10:15:30+01:00[Europe/Paris] (это значение по умолчанию в 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) (это значение по умолчанию в Noda Time)

Если то, что вы ищете, это способ включить ZonedDateTime или подобные данные в API стандартным образом, моя личная рекомендация состояла бы в том, чтобы передать имя часового пояса в отдельном поле. Таким образом, каждая часть данных так же хороша, как и может быть. Например, в JSON:

{
  "timestamp": "2011-12-03T10:15:30+01:00",
  "timezone": "Europe/Paris"
}

Ответ 2

Ответ Matt Johnson является правильным. Я просто добавлю несколько мыслей.

Часовой пояс против смещения от-UTC

offset-from-UTC - это всего лишь несколько часов, минут и секунд впереди/позади UTC. В одиночку это делает дату-время в определенный момент времени. Но это не так информативно, как включение официального названия часового пояса.

Пока еще нет стандарта для включения имени часового пояса, я надеюсь, что другие последуют за лидерами классов java.time при добавлении в квадратных скобках названия часового пояса. Этот формат кажется мне разумным, так как было бы просто усечь часть квадратной скобки, чтобы быть обратно совместимой с не-подкованным программным обеспечением.

Например:
2011-12-03T10:15:30+01:00[Europe/Paris]. Если бы данные были только 2011-12-03T10:15:30+01:00, мы могли бы идентифицировать момент на временной шкале, но не смогли бы настроить другие моменты в одном и том же духе, поскольку мы не знали бы, какие правила корректировки применяются. Зоны, такие как Europe/Zagreb, Africa/Brazzaville, Arctic/Longyearbyen и Europe/Isle_of_Man, разделяют смещение +01:00, но они могут иметь другие изменения, отличные от других Europe/Paris. Поэтому, если вы попытаетесь добавить три дня к значению 2011-12-03T10:15:30+01:00, вы действительно не можете точно вычислить результат, потому что не знаете, какие корректировки могут потребоваться для применения, например, сокращения DST, которые могут возникать в течение этих трех дней.

Часовой пояс определяет набор правил обработки аномалий, таких как Летнее время (DST). Политики во всем мире пользуются корректировками своих часовых поясов или даже переопределяют их. Поэтому эти правила часто меняются. Подумайте о часовом поясе как совокупности смещений с течением времени, много периодов времени в истории, где каждый период имел особое смещение в использовании в этой конкретной области.

Вы можете думать о часовом поясе как о наборе значений offset-from-UTC. В America/Los_Angeles часть этого месяца занимает 8 часов меньше UTC, а часть года будет на 7 часов меньше UTC. Это делает 2 пункта данных, собранных как часть этого часового пояса.

Другой пример: в предыдущие годы Турция проводила часть каждого года на 2 часа раньше UTC и часть каждого года на 3 часа вперед. В 2016 году это изменилось на неопределенное время на 3 часа вперед. Таким образом, несколько точек данных в часовом поясе Europe/Istanbul.

Просто используйте UTC

Лично я не вижу большого значения даже при использовании таких значений, как 2011-12-03T10:15:30+01:00. Без часового пояса вы можете использовать только UTC. В этом случае 2011-12-03T09:15:30Z (9 AM вместо 10 AM).

Как правило, наилучшей практикой является использование UTC при хранении и обмене значениями даты и времени. Подумайте о UTC как одноразовом времени, причем значения зонирования или смещения являются просто вариациями.