[1] [[日時表示]]においてまたは単独で、 [[標準時]]や[[時間帯]]、[[時差]]を表現するには、様々な方法があります。 * 一般的な呼称 [2] 文脈により明らかな場合、「[[標準時]]」や「[[夏時刻]]」やそれらのバリエーションや、 「[[現地時間]]」のような語で表すことがあります。 ;; 各項を参照。 * 法令上の呼称 [3] [[法定時刻]]の呼称は、 「[[標準時]]」のような一般的な語しか定められていないケースも多いですが、 「[VAR[地域名]][[標準時]]」のように[[地名]]で修飾された語が定義されている場合もあります。 ;; 具体例は[[法定時刻]]および各地の[[標準時]]の項を参照。 [4] [[夏時刻]]を用いる場合、ほとんどは冬季の[[時刻]]を[[標準時]]と呼び、 それよりも進んだ夏季の[[時刻]]を[[夏時刻]]と呼びます。 [100] [[アイルランド]]の[[法令]]では、夏季の[[時刻]]が[[標準時]]とされており、 それより1時間遅い冬季の[[時刻]]が[[冬時刻]]とされています。 [99] [[ナウル]]では、[[法令]]で[[ナウル標準時]]という呼称で定義された[[時刻]]は使用されず、 [[ナウル代替時]]と呼ばれる[[時刻]]が[[標準時]]として使われています。 [5] ほとんどの場合、こうした[[時刻]]の名称は、 [[標準時]]の改正があると新しい[[時刻]]に付け替えられます。 つまり、ある名称が指す[[時刻]]が、改正の瞬間に切り替わります。 [6] 一方[[夏時刻]]を実施する場合、[[夏時刻]]は[[標準時]]の改正とはみなさず、 並行する異なる[[時刻]]として扱うことが多いようです。 * 時差表記 [35] [[時差]]は、2つの[[時刻]]の[[差]]によって表現されます。 ある時刻系が他の時刻系よりも早くある時刻値に到達するなら、 そちらの時刻系が「進んでいる」、他方の時刻系が「遅れている」といいます。 [172] 一般人向けの場合、例えば旅行ガイド等では、本国の時刻を基準とし、 それとの[[時差]]により、他の地域の[[標準時]]や[[夏時刻]]を説明するのが普通です。 [EG[ [173] 例えば、[[日本]]では、[[日本]]の時刻を基準に、[[台湾]]は1時間遅れているなどといいます。 ]EG] [174] 学術的な場面や多数の時刻を扱う場合などは、[[世界時]]を基準にすることが多いです。 [175] 進んでいることを [CODE[+]]、遅れていることを [CODE[-]] と表記し、 [[時差]]の[[時]]と[[分]] (と場合によっては[[秒]]) を表記して[[時差]]を記述することがよくあります。 [EG[ [176] [[日本の標準時]]は [[UTC]] より9時間早いので [TZ[+09:00]] と表し、 [[印度の標準時]]は [[UTC]] より5時間半早いので [TZ[+05:30]] と表します。 [[ハワイ]]の[[標準時]]は [[UTC]] より10時間遅いので [TZ[-10:00]] と表します。 ]EG] [177] ただし、[[符号]]は逆にすることもままありますから、注意が必要です。 ;; [8] [[時差の表]]を見ると、歴史的にも[[符号]]の表現が2種類あり、 どちらが正しい、どちらが優勢とも言い難いことがわかります。 [76] (主に[[自然言語]]文で) 「GMT-9」、「UTC+9」、「JST+1」 のような慣用的な表記が用いられることがあります。 基準となる[[時間帯]]と、そこからの[[時差]]を表しています。[[符号]]の意味は文脈により逆転するので注意が必要です。 [17] [[差]]の値は、[[時]]、[[分]]、[[秒]]の組で表現することが多いですが、 [[時]]を単位とする[[小数]]で表すこともあります。 [EG[ [19] 例えば [TZ[+08:30]] は、 [N[+8.5]] とも表せます。 ]EG] [9] [[JavaScript]] の [CODE[getTimezoneOffset]] は、 [[UTC]] との[[時差]]を[[分]]単位の[[数値]]として返します。 [[UTC]] よりも進んでいることを[[負]]で表しています。 [36] [[timestamp (Amazon Ion)]] のバイナリー形式は、[[分]]単位の整数で表します。 [20] 現在の[[近代的標準時制度]]でカバーされる[[時刻]]のみ扱う場合には、 [[UTC]] と[[整数]][[時]]単位の[[時差]]の他に、 15分、30分、45分の[[時差]]も扱える必要があります。 歴史的な[[時差]]や、[[船内時]]その他の分野依存の[[時刻]]を想定するなら、 任意の[[秒]] (求める[[精度]]次第では[[秒の小数部]]) まで扱える形で[[時差]]を記述できる必要があります。 [21] [[UTC]] との[[時差]]をどこまで認めるかは、記述形式によって違います。 現在の[[標準時制度][近代的標準時制度]]で現に用いられている[[時刻]]を扱うには、 [TZ[+14:00]] - [TZ[-12:00]] の範囲を扱える必要があります。 これで十分かどうかは、はっきりしません。 ;; [39] [[Oracle]] はこの範囲に制限しています。 [SEE[ [[SQLの日時形式]] ]] [22] [[ISO 9660の日時形式]]は [TZ[-12:00]] から [TZ[+13:00]] まで15分単位で指定できます。 [43] [[TRON時間]] ([[BTRON]] の[[システム時間]]) は±12時間の[[秒]]単位です。 -*-*- [15] [[差]]として表現する方法以外に、ある地点の[[正午]]や[[正子]]の他の地点の[[時刻]]を表示する方式があります。 [[UTC]] の[[正午]]を基準にすると世界各地の[[時刻]]のほとんどが同じ1日の[[時刻]]として表せ、 わかりやすいというメリットがあります。 ;; [16] 一方[[差]]としての表現は、[[負]]で端数がある時に少し計算がややこしくなるというデメリットがあります。 -*-*- [FIG(short list)[ [194] [[時差]]の記述形式 - [[HTMLの時間帯表記]] - [[インターネットメールの時間帯表記]] - [[RFC 3339の日付形式]]のもの - [[W3C-DTF]]のもの - [[ISO 8601の日時形式]]のもの - [CODE(XML)@en[[[xs:dateTime]]]] のもの - [[環境変数[CODE[TZ]]]] ([[POSIX時間帯]]) - [CODE[SYS$TIMEZONE_DIFFERENTIAL]] - [[MySQLの時間帯文字列]] - [[XMPの日時形式]] - [CODE[iodef:TimezoneType]] - [[Sieveの日時形式]] - [CODE[]] - [CODE[]] のもの - [[timestamp (Amazon Ion)]] - [CODE[urn:oasis:names:tc:xacml:3.0:entity:time‑zone]] - [CITE[[[JSON Timestamps]]]] - [CODE[Timezone:]] - [[ISO 9660の日時形式]] ]FIG] [41] [CITE[[[MHonArc]] Resources: TIMEZONES]], [TIME[2022-07-13T08:36:20.000Z]], [TIME[2004-03-22T03:44:49.095Z]] [42] [CITE@ja[[[TimeZone]] - Eureka]], [[TAKANASHI Mizuki]], [TIME[2022-07-13T08:37:45.000Z]], [TIME[2005-01-27T09:52:08.307Z]] [53] いわゆる [[IoT端末]]が送出するデータで、 16ビットのうち最上位が[[符号]]、下位15ビットが[[分]]単位の[[整数]]として記述されることがあります。 * 標準時夏時刻時差表記 [44] [[tzdata]] は各国[[法令]]に従い、 [[標準時]]を[[夏時刻]]と[[冬時刻]]のいずれにするか、 [[時差]]の[[正負]]を区別しています。 [45] [[TRON時間]]の実装では[[標準時]]からの[[時差]]は ±12時間 ([[分]]単位) とされます。 * 名前識別子表記 @@ 長い名前 @@ 略号 [89] [[CLDR]] には[[時間帯]]の名前の[[翻訳]]データが含まれています。 [[CLDR]] は地域名などを使った時刻の名称を定めると共に、 [[tzdata]] の[[時間帯]]履歴のうちのある期間の時刻がどの名称に相当するかの対応付けを持っています。 [10] 名前による表記は、多くの場合、[[時間帯]]を表しています。 ただしその「[[時間帯]]」は、ある時点のものだったり、歴史的変遷を含むものだったりします。 [FIG(short list)[ - [[tzdata]] の識別子 - [[Windows時間帯]] - [[インターネットメールの時間帯表記]] - [[米軍時間帯]] - [CODE[[[Z]]]] - [[Rails時間帯]] - [CODE[u-tz]] - [CODE[QTIMZON]] - [CODE[:TimeZone]] ]FIG] [34] [[Compact Time Format]] は[[緯度経度]]による指定方法を定義しています。 その地点の[[時間帯]]を参照しています。 ([[経度]]が直ちに[[時差]]を表すものではないようです。) [SEE[ 地名による表示 (人間向け) については[[日時の暦法明記]] ]] [REFS[ - [88] [CITE[Time Zones - CLDR - Unicode Common Locale Data Repository]] ([TIME[2016-06-24 13:52:06 +09:00]]) - [214] [CITE@en[List of time zone abbreviations - Wikipedia, the free encyclopedia]] ( ([TIME[2016-06-14 16:19:41 +09:00]])) - [227] [CITE@en[Time Zone Abbreviations - Worldwide List]] ([TIME[2017-10-27 16:51:12 +09:00]]) ]REFS] [30] [CITE@en[TimeZone ([[Java SE]] 11 & JDK 11 )]] ([TIME[2019-06-06 09:27:08 +09:00]]) [38] [CITE[Federal Information Processing Standards Publication: representation of universal time, local time differentials, and United States time zone references for information interchange - fipspub59.pdf]], [TIME[2017-12-05T16:08:23.000Z]], [TIME[2022-03-23T03:41:44.248Z]] [47] [CITE@ja[Jelly StarのKickstarterキャンペーンは6月13日21時から! – OREFOLDER]], [TIME[2023-06-12T03:21:06.000Z]] >ESTというのは東部標準時のことで、日本時間とは14時間の差があります。なのでESTで8時といえば日本時間で22時になります。ただし、夏時間の期間はこれが13時間の差になります。 > 夏時間の期間は年によって違うようですが、だいたい3月から11月まで。6月は夏時間です。ただ、EST(東部標準時)の夏時間のことをEDT(東部夏時間)と呼びます。夏時間で別名があるのに、Jelly Starの開始時間はESTと書いてある…ということは夏時間ではない方で考えたほうが良いのかな?とも思っていたのですが、Unihertzのツイートで解決しました。 >「キャンペーンの開始まであと72時間」というツイートが2023年6月10日21時に投稿されています。この72時間後は6月13日21時です。なのでやっぱり夏時間で考えるのが正解のようですね。 * その他の方法の記述 [48] [[[CODE[z=]] (SDP)]] は次回 (現在) の[[夏時刻]]の[[期間]]を記述できます。 * 不明の明記 [18] [[時間帯]]不明を表す表記があることもあります。 [[時間帯のない日時]]として暗黙的に表されることもあります。 [SEE[ [[時間帯のない日時]] ]] * プロトコル [113] 各種[[日時形式]]における[[時間帯]]の扱いや、 [[計算機]]における[[日時]]の表現での[[時間帯]]の取り扱いについては、 [[日時形式]]を参照。 [75] 各[[時間帯]]表記が使われる場所は、それぞれの項と次の各項を参照。 [FIG(short list)[ - [[XDMにおける時間帯]] ]FIG] [29] [[時間帯]]自体を特に扱う[[プロトコル]]や[[言語]]もあります。 [FIG(short list)[ - [[TZDIST]] - [[VTIMEZONE]] - [[時間帯パターン]] ]FIG] [195] [[アプリケーション]]の用いる[[時間帯]]について、「プラットフォームと同じ」 と指定する方法が提供されている場合があります。 ;; [[システム時間帯]]参照。 [26] [[struct timezone]] * セキュリティー、プライバシー [14] [[時差の記述]]は、ときに [[fingerprinting vector]] となります。 [SEE[ [[日時のセキュリティー]]、[[日時のプライバシー]] ]] * その他 [23] [[TIME IND]] * 関連 [SEE[ [[日時の暦法明記]] ]] * メモ [13] [[RFC 2822]], [[son-of-RFC 1036]], [[usefor]] では数値形式を推奨。 [[HTTP]]では文字列「GMT」固定。 非標準の時間帯文字列を使う実装がかなりあった。今は少ないと思う。 各地で観測されている[[時間帯を表す文字列]]の一覧参照。 数値形式に、注釈で文字列を添える (eg. +0900 (JST)) のが、 [[RFC 2822]]の [[[CODE(822)@en[Received]]:]] 欄における推奨。だけど、そういうのを [[[CODE(822)@en[Date]]:]] 欄でやると意味の分からない足し算・引き算を やる訳の分からん実装 ([[Windows 95]] の [[Microsoft Exchange]] らしい。) があるという罠。 「-0000」は時間帯不明を表すという慣習があって、[[RFC 2822の日付形式]] で明文化された。 UTC との時差が整数分にならない時もこれを 使うといいらしい。(ほんとか? ; この話はどの仕様書にも 載ってない。; ていうか整数分にならない地域ってどこよ?) [[RFC 3339]] にこの話も載ってます。時差が整数分にならないのは、 過去にあったけど現在はないようです。 [[RFC 3339]] は、そうした 時間帯は他の適当な(表現可能な)時間帯に直すように指示しています。 ("-00:00" にしろとまでは言ってない。) - [25] 過去の[[リベリア]]では -00:44:30 を使っていたらしいです。 -*-*- [28] [[日時]]の記述に含まれる[[時間帯]]の情報は、 [[UTC]] との関係を通じて実際の[[時刻]]を特定するだけでなく、 その[[時間帯]]自体の情報を伝えるためにも使えます。 [[RFC 3339]] は、[[電子メール]]の[[日時]]の[[時差]]から、 返事がすぐに返ってくるか推測できる [SRC[>>27]] と例示しています ([[時差]]から昼間の時間帯がいつからいつまでかを推察できるという意味でしょう)。 [82] しかし [[HTTPの日時形式]]のように、 [[UTC]] に固定して、 送信者の[[時間帯]]の情報を[[日時]]に含めていないものもあります。 [[HTTP]] では相手の[[時間帯]]が処理に影響しませんし、[[利用者]]に表示することもないので不要なのです。 [83] [[電子メール]]であっても、[[日時]]は[[受信者]]の[[プラットフォーム]]の[[時間帯]]の設定に合わせて表示し、 記述された[[時差]]の情報は使わない [[MUA]] が少なくありません。 あまり信用できる情報ではなく、[[利用者]]からは重視されていないということでしょう。 [REFS[ - [27] [CITE@en[RFC 3339 - Date and Time on the Internet: Timestamps]] ([TIME[2017-05-07 16:17:18 +09:00]]) ]REFS] [FIG(quote)[ [FIGCAPTION[ [7] [CITE[タイムゾーン呪いの書 - Qiita]] ([TIME[2018-02-06 15:17:04 +09:00]]) ]FIGCAPTION] > 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" として解釈されます。 ]FIG] [FIG(quote)[ [FIGCAPTION[ [11] [CITE@en[Strava Developers]] ([TIME[2018-03-17 12:36:57 +09:00]]) ]FIGCAPTION] > "timezone" : "(GMT-08:00) America/Los_Angeles", > "utc_offset" : -28800, ]FIG] [FIG(quote)[ [FIGCAPTION[ [12] [CITE@en[Strava Developers]] ([TIME[2018-03-17 12:36:57 +09:00]]) ]FIGCAPTION] > "timezone" : "(GMT-08:00) America/Los_Angeles", > "utc_offset" : -28800, ]FIG] [24] [CITE[25.4.1. Time Functions]] ([TIME[2019-04-25 11:08:19 +09:00]]) [31] [CITE['''['''tz''']''' Java & Rearguard]] ([TIME[2019-06-09 03:06:05 +09:00]]) [FIG(quote)[ [FIGCAPTION[ [32] [CITE@ja[世界初のGPS ソーラーウオッチ<セイコー アストロン>より、ロサンゼルス・エンゼルス 大谷翔平選手をイメージしたコラボレーション限定モデル第二弾を発売:時事ドットコム]] ([TIME[2019-10-16 08:58:26 +09:00]]) ]FIGCAPTION] > 大谷翔平選手が所属するロサンゼルス・エンゼルスのチームカラーである「レッド」がアクセントカラーとしてさりげなく輝くスタイリッシュなデザインです。セイコー独自の表面硬化処理「スーパー ブラックダイヤシールド(※3)」を施した漆黒のベゼル上にレイアウトされる都市コードは、通常、「LAX」と表示される「UTC-8」のゾーンを、エンゼルスのホームタウンであるアナハイムを示す「ANA」の文字を特別に記し、アナハイムが属する「UTC-8」 の表示とともに赤色で強調し、限定モデルならではの特別なデザインに仕上げています。 ]FIG] [FIG(quote)[ [FIGCAPTION[ [33] [CITE@ja[ジョンズ・ホプキンス健康安全保障センター、世界経済フォーラム、ビル&メリンダ・ゲイツ財団が広域流行病シミュレーション・ライブ配信を主催:時事ドットコム]] ([TIME[2019-10-21 09:38:47 +09:00]]) ]FIGCAPTION] > 一般市民は、東部標準時(夏時間)午前8時50分~午後0時30分に英語で実施される同時進行のバーチャル演習に、centerforhealthsecurity.org/event201/より登録・参加いただけます。 ]FIG] [37] [CITE@ja[.NET CoreでWindowsとLinuxでタイムゾーンを識別するID表記が異なるという話 - 銀の光と碧い空]], [[tanaka_733]], [TIME[2021-11-30T09:51:13.000Z]] > .NET Coreで特定のTimeZoneを取得する場合、Windowsな人はこのようなコードを書くと思います。 [PRE(code)[ System.TimeZoneInfo.FindSystemTimeZoneById("Tokyo Standard Time"); ]PRE] 当然Windowsでは動くのですが、Unix系システムの上(多いと思われるのがLinuxコンテナ上)で動かすとこんなエラーが発生します。 [40] [CITE[ソフト工作室]], [TIME[2022-06-20T05:41:17.000Z]], [TIME[2003-12-31T07:21:03.043Z]] [46] [CITE@en[CLACode_SRI/cla_code.md at conla · CL-KIITA/CLACode_SRI · GitHub]], [TIME[2023-04-10T14:33:27.000Z]] > 更新日の形式 ISO8601 基本形式の日付部、日本標準時は無標(あるいはプリフィックス 0000)、協定世界時はプリフィックス[CODE[utc0]]、、ほかの地域は IATA タイムゾーンコードに従う(末尾 0 パディング)プリフィックスをもつ。 > POSIX 正規表現:R"[a-z0-9]{4}" - [49] [CITE@ja[Xユーザーの旅し隊さん: 「アゴダで予約したら十勝時間という新たなタイムゾーンができていた。 https://t.co/viEq8RKPQt」 / X]], [TIME[午後10:56 · 2024年11月5日][2024-11-05T13:56:49.000Z]], [TIME[2024-11-07T01:50:10.000Z]] - [50] [CITE@ja[Xユーザーのタフィーさん: 「@Trip_Rapid こちとら知多時間やで…! https://t.co/VK0tow3UOq」 / X]], [TIME[午後11:08 · 2024年11月5日][2024-11-05T14:08:11.000Z]], [TIME[2024-11-07T01:50:10.000Z]] [51] このサービスでは所在地 + 「時間」を表示上の時刻の名称に機械的に使っている? [52] [CITE@ja[JM-LL301 GPS Tracker Communication Protocol_v1.0_20210823.pdf]], [TIME[2023-01-18T03:29:16.000Z]], [TIME[2025-10-15T06:25:35.987Z]]