一般的な呼称

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

法令上の呼称

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

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

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

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

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

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

時差表記

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

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

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

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

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

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

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

名前識別子表記

[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] 日時のセキュリティー、日時のプライバシー参照。

メモ

[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 が少なくありません。 あまり信用できる情報ではなく、利用者からは重視されていないということでしょう。