Методология API. Работа с часовыми поясами

Question

Я занимаюсь разработкой API, и мне просто интересно, может ли кто-нибудь посоветовать следующую ситуацию ...

Время моего веб-сервера установлено на UTC, часовой пояс PHP настроен на использование UTC.Все времена в моей базе данных сохраняются как временные метки Unix, и каждый пользователь хранится в базе данных вместе со своим часовым поясом.

Теперь мой вопрос ... должен ли API использовать сохраненный часовой пояс пользователей и корректировать временные метки перед отправкойих, или он должен отправлять метку времени UTC и полагаться на то, что клиент запрашивает часовой пояс из API, прежде чем его увидит пользователь?

Как другие основные API работают с метками времени?

Answer 1

Я использую следующую гипотезу (в спецификации lingo):

API ДОЛЖНЫ обслуживать время UTC, а клиент / потребитель ДОЛЖЕН их правильно локализовать, если это необходимо. API ДОЛЖЕН принимать даты и время UTC, и МОЖЕТ принимать локализованные даты и время для установки.

Я всегда использую метки времени UTC RFC3339 ISO в следующем формате: YYYY-MM-DD HH:MM:SSZ. Ответ от API может выглядеть так:

{
  'title' : 'Foo',
  'due_date': '2011-12-13 12:00:00Z'
}

В то время как я в то же время разрешаю клиентам указывать осведомленное время. Поэтому я допускаю следующее:

1. http://api.example.com?title=Foo&due_date=2011-12-13 13:00:00+0100 -> конвертируется в UTC и сохраняется
2. http://api.example-com?title=Foo&due_date=2011-12-13 12:00:00Z -> UTC

Вы можете использовать ту же гипотезу, используя метки времени UNIX (лично я не хочу использовать метки времени UNIX, поскольку они имеют ограниченную дату начала (1970 г.) и дату окончания (2038 г.)).

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

{
  'title' : 'Foo',
  'due_date' : {
                'utc': '2011-12-13 12:00:00Z',
                'converted_from' : '2011-12-13 13:00:00+0100'
  }
}

из, если вы предпочитаете метки времени UNIX:

{
  'title' : 'Foo',
  'due_date' : {
               'utc': 1326456000,
               'original_offset' : 3600
  }
}                  

Answer 2

Это на самом деле не ответ, но используйте то, что имеет смысл для вашего API.

Многие сервисы, к лучшему или к худшему, всегда будут взаимодействовать только с одним часовым поясом (в основномУНИВЕРСАЛЬНОЕ ГЛОБАЛЬНОЕ ВРЕМЯ).Если это работает для приложения, то отлично.

Однако, если часовой пояс имеет значение any , то очевидно, что ошибочно не посылать вместе эту информацию, ни в виде одного фрагмента (например, строки даты с часовым поясом), ни отдельно, а рядом(например, дата, часовой пояс).