Идентификация часовых поясов в ISO 8601

Question

Нет, я не говорю о смещениях зоны --- они могут меняться в течение года для региона на основе, например, DST. Я говорю о фактическом time zones maintained by IANA. Я понимаю, что это не, поддерживаемый ISO 8601, правильно?

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

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

Answer 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-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) (это значение по умолчанию в N ода времени)

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

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

Answer 2

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

часового пояса по сравнению с офсетным из-UTC

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

Пока еще нет стандарта для включения имени часового пояса, я надеюсь, что другие последуют за лидерами классов 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, которое может возникать в течение этих трех дней.

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

Вы можете думать о часовом поясе как о наборе значений смещения от 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 часов вместо 10 часов утра).

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