Методология API. Работа с часовыми поясами
Я разрабатываю API, и мне просто интересно, если кто-то мог бы посоветовать следующую ситуацию...
Время моего веб-сервера было установлено на UTC, часовой пояс PHP был настроен на использование UTC. Время в моей базе данных сохраняется как метки времени Unix, и каждый пользователь хранится в базе данных вместе со своим часовым поясом.
Теперь мой вопрос: должен ли API использовать сохраненный пользователем часовой пояс и корректировать временные метки перед их отправкой, или он должен отправлять временную метку UTC и полагаться на то, что клиент запрашивает часовой пояс из API, прежде чем его увидит пользователь?
Как другие основные API работают с метками времени?
2 ответа
Я использую следующую гипотезу (в спецификации 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'
}
Хотя я в то же время позволяю клиентам указывать осведомленные даты и времени. Поэтому я разрешаю следующее:
http://api.example.com?title=Foo&due_date=2011-12-13 13:00:00+0100
-> конвертируется в UTC и сохраняется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
}
}
Это на самом деле не ответ, но используйте то, что имеет смысл для вашего API.
Многие сервисы, в лучшую или в худшую сторону, всегда будут общаться только в одном часовом поясе (в основном, UTC) Если это работает для приложения, то отлично.
Однако, если часовой пояс имеет какое-либо значение, то, очевидно, ошибочно не посылать эту информацию вместе, либо в виде одного фрагмента (например, строки даты с часовым поясом), либо отдельно, но рядом (например, дата, часовой пояс).