APIの従来のタイムゾーンはありますか？

Question

タイムスタンプを処理する必要のある認証ヘッダーを持つAPIを開発中です。将来のタイムスタンプの使用をさらに必要とする可能性があり、私たちが使用するタイムゾーンが一貫していたいと思うので、APIの従来のタイムゾーンがあるかどうかを知りたいと思います。たとえばUTC + 0です。いくつかのケースでは、事前

Answer 1

で

おかげで、あなたは、（標準Dateヘッダなど）がHTTPヘッダを見つけるRFC5322フォーマット（別名RFC2822、RFC822）です。例えば：DateヘッダでTue, 31 Jan 2017 17:45:00 GMT

、タイムゾーンの略語は、RFC5322フォーマットは、他のタイムゾーンを可能にするにもかかわらず、（この目的のためにUTCに相当する）は常に"GMT"あります。

上記のフォーマットは、実際には好まれていません。あなたは確かにあなた自身のHTTPヘッダーのために望む任意のフォーマットを使用することができます。

より良いフォーマットはRFC3339 formatです。これは、拡張フォーマットISO8601に似ています。例は2017-01-31T17:45:00Zです。最後のZは「GMT」または「UTC」と同じ「ズールー」時間を示します。しかし、あなたはまた、米国太平洋時間帯における同等の現地時間として、UTCからのオフセットのタイムゾーンを指定することができます。2017-01-31T09:45:00-08:00

あなたは1485884700のようなUnixの時間数を持っている場合は、タイムゾーンが常に UTCです。しかし、これは人間が読めるものではなく、エポックや精度がどのように使われているかについてのコンテキストを提供していないため、良い交換フォーマットではありません。人は外部でそれらのことを知る必要があります。 HTTPヘッダーやXML、JSONにはあまり適していません。

XML/JSONリクエストの本文については、ISO8601のみを使用してください。人々が使用する他のいくつかのフォーマットがありますが、推奨されていません。

どのタイムゾーンを使用するべきかは、コンテキストに完全に依存しています。 タイムスタンプ - 現在の時刻を記録して記録する場合は、実際には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（米国東部時間）が別のフィールドに表示されます。

これは、仕事が将来の月に引き続き続くためです。3月12日、米国東部時間帯はUTC-5からUTC-4に変更されます。したがって、1つのオフセットを指定することはできず、UTCを使用することもできません。

また、単一の発生であっても、一部の国では、毎時tz databaseに数十件の更新があるため、タイムゾーンとDSTの規則について心を変え続けていることに注意してください。将来の日時のオフセットを計算する場合は、ロールオーバーするまでにオフセットが政府によって変更されていることがあります。