Есть ли обычный часовой пояс для API?

Question

Мы работаем над API, который имеет заголовок аутентификации, в котором должна обрабатываться метка времени. Поскольку в будущем мы можем нуждаться в большем использовании временных меток и хотим быть последовательными в том, в каком часовом поясе мы используем, я хотел бы знать, существует ли традиционный часовой пояс для API. UTC + 0, например.

Заранее спасибо

Answer 1

В некоторых случаях, вы увидите, что HTTP-заголовки (например, стандартный Date заголовка) в RFC5322 формате (ака RFC2822, RFC822). Например: Tue, 31 Jan 2017 17:45:00 GMT

В заголовке Date, временная зона аббревиатура всегда "GMT" (что эквивалентно UTC для этой цели), даже при том, что формат RFC5322 позволяет других временных зон.

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

Гораздо лучший формат - RFC3339 format. Это похоже на расширенный формат ISO8601. Пример: 2017-01-31T17:45:00Z. В конце Z указано время «Зулу», которое совпадает с GMT или UTC. Тем не менее, вы можете также указать смещение часового пояса от UTC, таких как локальное время в часовом поясе США Тихого океана: 2017-01-31T09:45:00-08:00

Если у вас есть номера времени Unix, как 1485884700, часовой пояс всегда UTC. Однако это не очень хороший формат обмена, поскольку он не читается человеком и не содержит контекста того, какая эпоха или точность используются. Нужно было бы знать эти вещи внешне. Это не подходит для заголовков HTTP, а также для XML или JSON.

Если вы говорите о теле ваших запросов XML/JSON, вы должны использовать только ISO8601. Есть несколько других форматов, которые люди используют, но они не рекомендуются.

Что касается того, какой часовой пояс вы должны использовать - это полностью зависит от контекста. Если вы находитесь timestamping - где вы берете текущее время и записываете его, то вы действительно можете работать с UTC. Я думаю, что для авторизации это было бы разумно. Вы также можете работать в локальное время, если вы предоставили смещение от UTC вместе с ним, чтобы не было двусмысленности.

Однако вы сказали (в комментариях), что ваши данные содержат информацию о вакансиях. Это звучит так, как будто вы говорите о времени в будущем - и это исключение из правила «всегда UTC». Каждый раз, когда вы говорите о времени в будущем, вам нужно выразить это с точки зрения по местному времени, в самой прямой форме, которую вы можете, и вам также необходимо предоставить идентификатор (а не смещение) часового пояса, который применяется.

Например, если я говорю о вакантное, я мог бы сказать в моих данных:

{ 
    "job": "dishwasher", 
    "available: "2017-02-13", 
    "start": "08:00", 
    "end": "16:00", 
    "tz": "America/New_York" 
} 

Эти значения будут следовать ISO8601 формат даты только и только время (или, если я хотел объединить их 2017-02-13T08:00) - и не будет указан часовой пояс. Вместо этого идентификатор часового пояса IANA America/New_York (для восточного времени США) предоставляется в отдельном поле.

Это важно, потому что, возможно, работа продолжается в будущие месяцы.12 марта восточный часовой пояс США изменится с UTC-5 на UTC-4. Поэтому нельзя указывать одно смещение, и вы не можете использовать UTC.

Кроме того, даже в одном случае имейте в виду, что некоторые страны продолжают менять свое мнение о том, что такое их часовой пояс и правила DST, поэтому каждый год обновляются десятки обновлений для tz database. Если вы должны были рассчитать смещение для даты и времени в будущем, к тому моменту, когда он перевернется, вы можете обнаружить, что смещение было изменено правительством.