一般的な呼称

[2] 文脈により明らかな場合、「標準時」や「夏時刻」やそれらのバリエーションや、 「現地時間」のような語で表すことがあります。

法令上の呼称

[3] 法定時刻の呼称は、 「標準時」のような一般的な語しか定められていないケースも多いですが、 「地域名標準時」のように地名で修飾された語が定義されている場合もあります。

[4] 夏時刻を用いる場合、ほとんどは冬季の時刻を標準時と呼び、 それよりも進んだ夏季の時刻を夏時刻と呼びます。

[100] アイルランドの法令では、夏季の時刻が標準時とされており、 それより1時間遅い冬季の時刻が冬時刻とされています。

[99] ナウルでは、法令でナウル標準時という呼称で定義された時刻は使用されず、 ナウル代替時と呼ばれる時刻が標準時として使われています。

[5] ほとんどの場合、こうした時刻の名称は、 標準時の改正があると新しい時刻に付け替えられます。 つまり、ある名称が指す時刻が、改正の瞬間に切り替わります。

[6] 一方夏時刻を実施する場合、夏時刻は標準時の改正とはみなさず、 並行する異なる時刻として扱うことが多いようです。

時差表記

[35] 時差は、2つの時刻の差によって表現されます。 ある時刻系が他の時刻系よりも早くある時刻値に到達するなら、 そちらの時刻系が「進んでいる」、他方の時刻系が「遅れている」といいます。

[172] 一般人向けの場合、例えば旅行ガイド等では、本国の時刻を基準とし、 それとの時差により、他の地域の標準時や夏時刻を説明するのが普通です。

[174] 学術的な場面や多数の時刻を扱う場合などは、世界時を基準にすることが多いです。

[175] 進んでいることを +、遅れていることを - と表記し、 時差の時と分 (と場合によっては秒) を表記して時差を記述することがよくあります。

[177] ただし、符号は逆にすることもままありますから、注意が必要です。

[76] (主に自然言語文で) 「GMT-9」、「UTC+9」、「JST+1」 のような慣用的な表記が用いられることがあります。 基準となる時間帯と、そこからの時差を表しています。符号の意味は文脈により逆転するので注意が必要です。

[17] 差の値は、時、分、秒の組で表現することが多いですが、 時を単位とする小数で表すこともあります。

[9] JavaScript の getTimezoneOffset は、 UTC との時差を分単位の数値として返します。 UTC よりも進んでいることを負で表しています。

[20] 現在の近代的標準時制度でカバーされる時刻のみ扱う場合には、 UTC と整数時単位の時差の他に、 15分、30分、45分の時差も扱える必要があります。 歴史的な時差や、船内時その他の分野依存の時刻を想定するなら、 任意の秒 (求める精度次第では秒の小数部) まで扱える形で時差を記述できる必要があります。

[21] UTC との時差をどこまで認めるかは、記述形式によって違います。 現在の標準時制度で現に用いられている時刻を扱うには、 +14:00 - -12:00 の範囲を扱える必要があります。 これで十分かどうかは、はっきりしません。

[22] ISO 9660の日時形式は -12:00 から +13:00 まで15分単位で指定できます。

[15] 差として表現する方法以外に、ある地点の正午や正子の他の地点の時刻を表示する方式があります。 UTC の正午を基準にすると世界各地の時刻のほとんどが同じ1日の時刻として表せ、 わかりやすいというメリットがあります。

名前識別子表記

[89] CLDR には時間帯の名前の翻訳データが含まれています。

[10] 名前による表記は、多くの場合、時間帯を表しています。 ただしその「時間帯」は、ある時点のものだったり、歴史的変遷を含むものだったりします。

[228] OWL-Time の time:timeZone についての仕様書の NOTE は、 timeanddate.com の時間帯英字略号リスト >>227 の掲載各 Webページの URL を値として使うことができる >>229 と述べています。 なぜ規定ではなく NOTE なのかは不明です。また他に tzdata に基づく URL も使えるとしています。(tzdata はともかく timeanddate.com は人間向けの Webサイトであり、 OWL での処理に有用なのかは謎です。 実利用者がいるのかも不明です。)

不明の明記

[18] 時間帯不明を表す表記があることもあります。

プロトコル

[113] 各種日時形式における時間帯の扱いや、 計算機における日時の表現での時間帯の取り扱いについては、 日時形式を参照。

[75] 各時間帯表記が使われる場所は、それぞれの項と次の各項を参照。

[29] 時間帯自体を特に扱うプロトコルや言語もあります。

[195] アプリケーションの用いる時間帯について、「プラットフォームと同じ」 と指定する方法が提供されている場合があります。

セキュリティー、プライバシー

[14] 日時のセキュリティー、日時のプライバシー参照。

その他

[23] TIME IND

メモ

[13] RFC 2822, son-of-RFC 1036, usefor では数値形式を推奨。 HTTPでは文字列「GMT」固定。

非標準の時間帯文字列を使う実装がかなりあった。今は少ないと思う。 各地で観測されている時間帯を表す文字列の一覧参照。

数値形式に、注釈で文字列を添える (eg. +0900 (JST)) のが、 RFC 2822の Received: 欄における推奨。だけど、そういうのを Date: 欄でやると意味の分からない足し算・引き算を やる訳の分からん実装 (Windows 95 の Microsoft Exchange らしい。) があるという罠。

「-0000」は時間帯不明を表すという慣習があって、RFC 2822の日付形式 で明文化された。 UTC との時差が整数分にならない時もこれを 使うといいらしい。(ほんとか? ; この話はどの仕様書にも 載ってない。; ていうか整数分にならない地域ってどこよ?)

RFC 3339 にこの話も載ってます。時差が整数分にならないのは、 過去にあったけど現在はないようです。 RFC 3339 は、そうした 時間帯は他の適当な(表現可能な)時間帯に直すように指示しています。 ("-00:00" にしろとまでは言ってない。)

• [25] 過去のリベリアでは -00:44:30 を使っていたらしいです。

[28] 日時の記述に含まれる時間帯の情報は、 UTC との関係を通じて実際の時刻を特定するだけでなく、 その時間帯自体の情報を伝えるためにも使えます。 RFC 3339 は、電子メールの日時の時差から、 返事がすぐに返ってくるか推測できる >>27 と例示しています (時差から昼間の時間帯がいつからいつまでかを推察できるという意味でしょう)。

[82] しかし HTTPの日時形式のように、 UTC に固定して、 送信者の時間帯の情報を日時に含めていないものもあります。 HTTP では相手の時間帯が処理に影響しませんし、利用者に表示することもないので不要なのです。

[83] 電子メールであっても、日時は受信者のプラットフォームの時間帯の設定に合わせて表示し、 記述された時差の情報は使わない MUA が少なくありません。 あまり信用できる情報ではなく、利用者からは重視されていないということでしょう。