Как я могу написать дату ISO 8601 с часовым поясом, но без компонента времени

Question

ISO 8601 datetime с часовым поясом форматируется следующим образом:

2018-09-07T05:28:42Z

Однако мне нужно представить некоторые даты в моей системе, где точность составляет дни, а не секунды, что означает, что это будет календарная дата ISO 8601 . Календарные даты имеют следующий формат:

2018-09-07

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

Либо секунды, либо минуты и секунды могут быть опущены в базовом или расширенном форматах времени для большей краткости, но с пониженной точностью: [чч]: [мм], [чч] [мм] и [чч] являются В результате снижается точность временных форматов.

Отсюда кажется, что вы не можете опустить часы, поэтому я не мог написать календарную дату, подобную этой:

2018-09-07TZ

Похоже, что лучшее, что я могу сделать, это усечь до часа:

2018-09-07T00Z

Однако я не хочу этого делать, если смогу избежать этого, поскольку добавляю к дате больше точности, чем на самом деле. Дата означает «где-то в течение дня 07 сентября 2018 года в часовом поясе UTC», а не «где-то в полночь 07 сентября 2018 года в часовом поясе UTC».

Есть предложения?

Answer 1

Основной вопрос здесь (мне) кажется, что вы используете, чтобы записать свою дату / время.

Например, в C ++ вы можете сделать:

time_t n = std::time(NULL);

tm *now = std::localtime(&n);

std::cout << std::put_time(now, "%F %z") << '\n';

Это производит вывод как:

2018-09-07 -0700

Если ваш реальный вопрос заключается в том, соответствует ли это формату, указанному в ISO 8601, я считаю, что ответ - нет. Но его довольно легко произвести.

О, и, по крайней мере, ИМО, да, просто дата с часовым поясом может иметь совершенно хороший смысл. Даже если вы заботитесь только о дате, часовой пояс сообщает вам, когда эта дата начинается / заканчивается относительно других мест на земле, поэтому, если я скажу «1 января 2019 года по тихоокеанскому времени», кто-то в (скажем) Лондоне знает, что эта дата смещено на 7 часов от его местной даты.

Answer 2

Официально спецификация ISO 8601 не допускает дату с часовым поясом, если не указано время. Таким образом, если вы хотите оставаться совместимым с ISO 8601, вы не можете предоставить дополнительную информацию для значений только для даты, чем год, месяц и день (без обращения к временным интервалам, о которых речь пойдет ниже).

Один формат, который допускает , позволяет использовать это XML-схема (также известная как "XSD") в типе xs:date. Там это не обязательно, и сразу же следует за днем, например, 2018-09-07Z. Спецификация XSD вызывается в Разделе D.3 Отклонения от форматов ISO 8601 :

D.3.4 Разрешенный часовой пояс
Лексические представления для дата типов данных, разрешение gYearMonth, gMonthDay, gDay, gMonth и gYear необязательный указатель часового пояса.

Я понимаю, что вы не спрашивали о XSD, но это единственное известное мне нормативное указание, которое свободно доступно в Интернете, где указывается часовой пояс на дату, это отклонение от ISO 8601.

Как уже отмечали другие - думать о дате с часовым поясом довольно сложно. Во многих отношениях значение только для даты является неоднозначным. Подумайте, представил ли я вам такой календарь:

Указание на любую дату в этом календаре ничего не говорит мне о часовых поясах. Я могу дать календарь кому-то в другом часовом поясе, и он все еще сможет говорить о датах. Просто если мы оба указываем на «сегодня» одновременно, мы могли бы не указывать на одну и ту же дату. Таким образом, часовые пояса применяются только тогда, когда мы применяем временной контекст, будь то «сейчас» или определенный.

Однако мы склонны рационализировать все моменты времени в данный день с точки зрения часового пояса. В вашем примере «День UTC». Мы имеем в виду, что он работает с T00:00Z одного дня до T00:00Z следующего. Это обычно объясняется такими вещами, как xs:date, допускающим смещение часового пояса.

Если бы мы хотели быть строго совместимыми с ISO 8601 и представлять то же самое значение, мы должны были бы предоставить диапазон значений даты + времени, которые называются «временными интервалами» в разделе 4.4 спецификации ISO 8601, и являются разделены символом косой черты (/). Примером такого значения будет 2018-09-07T00:00Z/2018-09-08T00:00Z. Однако, будьте осторожны, потому что ISO 8601 говорит ничего о том, должна ли дата окончания интерпретироваться включительно или исключительно. Подробнее об этом здесь .

Другое представление интервала ISO 8601 допускает время начала и компонент duration , такой как 2018-09-07T00:00Z/P1D. Мне кажется, что это самый близкий полностью совместимый с ISO 8601 способ представления целой даты, интерпретируемой в UTC.

Тем не менее, лично мне, если бы мне нужно было передать часовой пояс с датой, я бы использовал 2018-09-07Z, даже если он не был строго совместим. Просто убедитесь, что все потребители ваших данных согласны с этим форматом. Если вы не можете этого сделать, просто наберите 2018-09-07 и назовите свое поле примерно как utcDate.

Answer 3

Дата с часовым поясом не имеет смысла, потому что часовые пояса корректируют часы / минуты в течение дня. Может быть, у вас есть дата и отдельный часовой пояс, который вам нужен для чего-то другого? Для случая, когда вам нужен часовой пояс для международной строки даты, вам также нужно время в формате часов: минут без этого часового пояса не будет иметь смысла.

Btw. W3C также имеет несколько примеров форматов даты и времени ISO8601 . И последнее, но не менее важное: вы всегда можете написать свой собственный парсер, например, с Antlr .

Также имейте в виду, что часовые пояса могут / будут меняться со временем - например, обычное время по сравнению с летним временем.