時差の記述

時差の記述

[1] 標準時時間帯時差を表現するには、様々な方法があります。

一般的な呼称

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

各項を参照。

法令上の呼称

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

具体例は法定時刻および各地の標準時の項を参照。

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

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

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

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

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

時差表記

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

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

[173] 例えば、日本では、日本の時刻を基準に、台湾は1時間遅れているなどといいます。

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

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

[176] 日本の標準時UTC より9時間早いので +09:00 と表し、 印度の標準時UTC より5時間半早いので +05:30 と表します。 ハワイ標準時UTC より10時間遅いので -10:00 と表します。

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

[8] 時差の表を見ると、歴史的にも符号の表現が2種類あり、 どちらが正しい、どちらが優勢とも言い難いことがわかります。

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

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

[194] 時差の記述形式

名前識別子表記

長い名前
略号

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

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

[228] OWL-Timetime: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 2822Received: 欄における推奨。だけど、そういうのを Date: 欄でやると意味の分からない足し算・引き算を やる訳の分からん実装 (Windows 95Microsoft Exchange らしい。) があるという罠。

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

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


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

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

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

[7] タイムゾーン呪いの書 - Qiita () <https://qiita.com/dmikurube/items/15899ec9de643e91497c>

JSR 310 の前身である Joda-Time では少し事情が異なります。org.joda.time.DateTimeUtils#getDefaultTimeZoneNames は、例えば "PST", "PDT" をともに "America/Los_Angeles" に対応させます。どうやら org.joda.time.format.DateTimeFormat.forPattern では間接的にこの getDefaultTimeZoneNames が使われているようで23、このため Ruby の Time.strptime や RFC とは異なり "2017-07-01 12:34:56 PST" は "2017-07-01 12:34:56 -07:00" として解釈されます。

[11] Strava Developers () <https://developers.strava.com/docs/reference/>

"timezone" : "(GMT-08:00) America/Los_Angeles",

"utc_offset" : -28800,

[12] Strava Developers () <https://developers.strava.com/docs/reference/>

"timezone" : "(GMT-08:00) America/Los_Angeles",

"utc_offset" : -28800,