一般的な呼称

[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 よりも進んでいることを負で表しています。

[36] timestamp (Amazon Ion) のバイナリー形式は、分単位の整数で表します。

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

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

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

[43] TRON時間 (BTRON のシステム時間) は±12時間の秒単位です。

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

[41] MHonArc Resources: TIMEZONES, 2022-07-13T08:36:20.000Z, 2004-03-22T03:44:49.095Z https://web.archive.org/web/20040322034327/http://www.etsimo.uniovi.es/~antonio/mhonarc/resources/timezones.html

[42] TimeZone - Eureka, TAKANASHI Mizuki, 2022-07-13T08:37:45.000Z, 2005-01-27T09:52:08.307Z https://web.archive.org/web/20050127094920/http://eureka.prits.jp/resources/etc/timezone.html

標準時夏時刻時差表記

[44] tzdata は各国法令に従い、 標準時を夏時刻と冬時刻のいずれにするか、 時差の正負を区別しています。

[45] TRON時間の実装では標準時からの時差は ±12時間 (分単位) とされます。

名前識別子表記

[89] CLDR には時間帯の名前の翻訳データが含まれています。 CLDR は地域名などを使った時刻の名称を定めると共に、 tzdata の時間帯履歴のうちのある期間の時刻がどの名称に相当するかの対応付けを持っています。

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

[34] Compact Time Format は緯度経度による指定方法を定義しています。 その地点の時間帯を参照しています。 (経度が直ちに時差を表すものではないようです。)

地名による表示 (人間向け) については日時の暦法明記

[30] TimeZone (Java SE 11 & JDK 11 ) (2019-06-06 09:27:08 +09:00) https://docs.oracle.com/en/java/javase/11/docs/api/java.base/java/util/TimeZone.html#getDisplayName(boolean,int,java.util.Locale)

[38] Federal Information Processing Standards Publication: representation of universal time, local time differentials, and United States time zone references for information interchange - fipspub59.pdf, 2017-12-05T16:08:23.000Z, 2022-03-23T03:41:44.248Z https://nvlpubs.nist.gov/nistpubs/Legacy/FIPS/fipspub59.pdf

[47] Jelly StarのKickstarterキャンペーンは6月13日21時から! – OREFOLDER, 2023-06-12T03:21:06.000Z https://www.orefolder.net/2023/06/unihertz-jelly-star-jun13-2/

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] z= (SDP) は次回 (現在) の夏時刻の期間を記述できます。

不明の明記

[18] 時間帯不明を表す表記があることもあります。 時間帯のない日時として暗黙的に表されることもあります。 時間帯のない日時

プロトコル

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

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

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

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

[26] struct timezone

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

[14] 時差の記述は、ときに fingerprinting vector となります。 日時のセキュリティー、日時のプライバシー

その他

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

[24] 25.4.1. Time Functions (2019-04-25 11:08:19 +09:00) http://www.cs.cmu.edu/Groups/AI/html/cltl/clm/node232.html#29143

[31] [tz] Java & Rearguard (2019-06-09 03:06:05 +09:00) https://mm.icann.org/pipermail/tz/2019-June/028122.html

[37] .NET CoreでWindowsとLinuxでタイムゾーンを識別するID表記が異なるという話 - 銀の光と碧い空, tanaka_733, 2021-11-30T09:51:13.000Z https://tech.tanaka733.net/entry/2020/02/timezone-id

.NET Coreで特定のTimeZoneを取得する場合、Windowsな人はこのようなコードを書くと思います。

System.TimeZoneInfo.FindSystemTimeZoneById("Tokyo Standard Time");

当然Windowsでは動くのですが、Unix系システムの上(多いと思われるのがLinuxコンテナ上)で動かすとこんなエラーが発生します。

[40] ソフト工作室, 2022-06-20T05:41:17.000Z, 2003-12-31T07:21:03.043Z https://web.archive.org/web/20031231071751mp_/http://village.infoweb.ne.jp/~tkiku/wsp/java/java67.html

[46] CLACode_SRI/cla_code.md at conla · CL-KIITA/CLACode_SRI · GitHub, 2023-04-10T14:33:27.000Z https://github.com/CL-KIITA/CLACode_SRI/blob/conla/docs/spec/cla_code.md#%E5%85%B1%E9%80%9A%E3%83%97%E3%83%AD%E3%83%91%E3%83%86%E3%82%A3%E9%83%A8

更新日の形式 ISO8601 基本形式の日付部、日本標準時は無標(あるいはプリフィックス 0000)、協定世界時はプリフィックスutc0、、ほかの地域は IATA タイムゾーンコードに従う(末尾 0 パディング)プリフィックスをもつ。

POSIX 正規表現:R"[a-z0-9]{4}"