時間の標準と形式

GMT (グリニッジ標準時)

グリニッジ (グリニッジとも訳される) は、イギリスのロンドンにある小さな町です。

17 世紀に英国の航海術は急速に発展しましたが、当時、海上航行には正確で正確な指示が急務であったため、英国王室は正確な経度を測定するためにグリニッジに天文台を設置しました。

その後、1884年にアメリカのワシントンで開催された国際経度会議で、グリニッジ天文台（旧地）を通過する経度を本初子午線（経度0度）として使用することが決定されました。同時に、この会議では世界を 24 のタイムゾーンに分割しました。経度 0 度に位置するタイム ゾーンはタイム ゾーン 0 です。

さて、機械式時計を購入したい場合、GMT をサポートしていると記載されている場合は、グリニッジ標準時の表示をサポートしていることを意味します。

UT (世界時)

1928 年に国際天文学連合は、主に 1 日の長さを測定するために使用される UT の概念を提案しました。1 日の長さが決まったら、この長さを 24 で割って 1 時間の長さを求めます。類推により、分と秒の長さを決定できます。

UT はまた、グリニッジ標準時を標準として使用しており、グリニッジの午前 0 時を 0 時と規定しています。

当時、1日の長さを測る方法は、地球が1周するのにどれくらいの時間がかかるかを天体観測によって測定することでした。しかし、天体観測には誤差があります。第二に、地球の自転はますます遅くなってきています。タイミング方法には早急な革新が必要です。

タイミング技術と国際原子時

人類の歴史の中で登場した計時方法は、一般に次の 3 つのカテゴリに分類できます。

• 一つは、砂時計、水時計、香時計（お香を焚く）など、何らかの一定の動きによって時間を表現しようとするものです。この方法には大きな欠陥があり、時間を測定する非常に大雑把な方法です。

• 2つ目は、太陽や月などの星を基準にして天体観測によって時刻を知る方法です。今、私たちは銀河の運動が一様なプロセスではないことを知っています。

• 3つ目は固定周波数振動によるもので、ガリレオは教会のシャンデリアを通して振り子の等時性、つまり振り子の角度が小さいとシャンデリアが1回揺れるのにかかる時間は同じであることを初めて発見しました。300～400年前の振り子時計は、基本的にこの原理を利用して実装されていました。

現在、人類に知られている最も正確な計時技術は原子時計であり、原子時計は原子の共鳴周波数基準に基づいて正確な時間を計算し維持します。その精度は 1 秒未満の誤差で数億年持続します。

その後、国際度量衡研究所はこの技術に基づいて、世界中の 400 台以上の原子時計を組み合わせ、1 秒がセシウム 133 の時刻であると決定しました。

サブ基底状態の 2 つの超微細エネルギー準位間の遷移放射振動は、9,192,631,770 サイクル持続します。この定義は国際原子時 (TAI) と呼ばれます。このようにして、時計の針がどれくらいの速さで回転するかについての統一基準が存在します。

国際原子時の秒は、1958 年 1 月 1 日のグリニッジ標準時の秒に基づいています。つまり、現時点では、国際原子時の第 2 の長さと世界時の第 2 の長さは同じです。

UTC (協定世界時)

UTC、協定世界時。協定世界時、世界統一時、国際協定時。国際原子時の秒に基づいています。しかし、UT が天文観測に基づいていることはわかっており、地球の速度がますます遅くなるにつれて、UT の 2 番目の長さはますます長くなるはずです。介入が実行されない場合、UTC と UT の間の誤差はますます大きくなります。

以下に示すように:

この状況が続けば、何年も何年も後、人類は協定世界時で午前3時に起床し、地下鉄に詰め込んで仕事に行くことになるかもしれない。したがって、UTCを人間の生活習慣に合わせるためには、UTCとUTCとの誤差を制御する必要があり、UTCはうるう秒を導入しました。いわゆるうるう秒とは、ある時点で通常の分よりも 1 秒長い分が人為的に決定されることを意味し、61 秒になります。このとき、1分59秒の後に2分0秒が来るはずですが、うるう秒が発生すると1分60秒になってしまいます。

受け入れられるようです。ただし、うるう秒がいつ追加されるかは予測できません。これは、国際地球回転サービス (IERS) によって実際の状況に基づいて定期的に決定されます。コンピューター プログラムにとって、うるう秒メカニズムは明らかに破壊的であり、関連する国際標準化団体はこの慣行を継続するかどうかについて議論しています。

概要: UTC/GMT

• GMT が最も古い国際時間標準であり、次に UTC が続きました。

• UTC は UT に近い必要があり、UT は GMT を標準にしているためです。厳密に言えば、UTC と GMT は同じものではありません。しかし、大まかに言えば、UTC を GMT と同等視することができ、一部の Web サイトやアプリケーションはまさにそれを行います。

• UTC 標準は長年使用されているためです。したがって、GMT という言葉を再び目にした場合、それは通常、国際時間ではなく、グリニッジが位置するタイム ゾーン、つまり 0 タイム ゾーンを指します。同時に、行政地域には通常、それぞれの地域に合わせて多くのタイム ゾーンの略語が存在しますが、残念なことに、この書き方では衝突が頻繁に発生します。

たとえば、CCT は、米国の中部標準時、オーストラリアの中部標準時、中国標準時、キューバ標準時を表すことができます。

したがって、 CCT 2022-08-03 11:56 と書くと誤解されやすいです。現時点では、日付と時刻を明確に記述する方法が非常に必要です。

タイムゾーンとUTCオフセット

現在のタイムゾーン表現は、ほとんどが UTC+オフセットで表されます。たとえば、北京は東 8 区にあり、時刻は UTC より 8 時間早いため、北京のタイム ゾーンを表す方法は UTC+08:00 です。地理的に定義されているのは東西 12 地区だけですが、時間をどこでどのように表現するかは、実際には地方行政命令によって異なります。したがって、UTC+12:00 はオフセットの上限ではありません。コンピュータの日付と時刻の設定を開くと、一部の国では日付と時刻が使用されていることがわかります。

UTC+14:00が使用されます。一部の国オフセットは、UTC+12:45 など、時間の正確な整数倍ではありません。

同時に、GMT+0800 を使用するアプリケーションも多くあり、効果は同じです。

日付と時刻の表現形式

2022年9月3日をどう表現するか？2022/09/03 ですか、2022-09-03 ですか、それとも 2022 年 9 月 3 日ですか? これも標準の問題ですが、各国の慣習に合わせた日時形式の標準が存在するのが現状ですが、同時に ISO 8601 や RFC3339 などの国際的な日時形式標準も多数存在します。

ソフトウェアによってさまざまな形式が採用されるため、プログラミング言語の日付標準ライブラリでは、日付と時刻の形式自体をエンコードする dateformat ツールを用意するのが一般的です。

ISO8601

国際標準 ISO 8601 は、国際標準化機構の日付と時刻の表現方法です。前述の UTC とは異なります。UTC は時刻標準であり、ISO 8601 は、ほとんどのプログラミング言語でサポートされている標準時刻形式です。 . .

ISO 8601 形式を使用すると、次の時間を明確に表現できます。

• グレゴリオ暦の日付

• 24 時間形式の時刻

• UTC タイムゾーン オフセット

• 時間間隔

• および上記の要素の組み合わせ。

ISO 8601 の表現は非常に柔軟なので、ここでは完全にリストすることはできませんが、最も一般的な日付と時刻の形式についてだけ説明しましょう。たとえば、次は ISO 8601 に準拠した日付と時刻の表現です。

2022-09-03T14:13:00Z、このタイムスタンプの中央にある T は日付と時刻を区切るために使用され、最後の文字 Z は 0 タイムゾーン (UTC または GMT 時刻) を表します。

例: プログラミング言語で UTC 時刻と ISO 形式を取得する

この例では、JavaScript を使用してブラウザーで日付オブジェクトを操作します。

• ブラウザを開いてランダムなページに入ります。空白のタブの方が良いでしょう。

• F12 キーを押して開発者ツールを開き、開発者ツールの上にある [コンソール] ボタンを見つけてクリックします。中国語のページが設定されている場合は、それがコンソールである必要があります。効果は以下の通りです。

  

  コンソールに入ると、いくつかのエラー メッセージや警告が表示されますが、これらは bing ページの問題であり、無視してかまいません。下の青い矢印では、JavaScript コードを直接記述してすぐに実行できます。

• コードを書く

  日付オブジェクトを作成します。

   x = new Date()
  

  コードを入力した後、Enter キーを押して実行します。

  

  コンソールが結果を返し、現在時刻が 2022 年 9 月 3 日土曜日の 14:44:29 であり、タイム ゾーン オフセットがグリニッジ タイム ゾーンから東に 8 時間であることを示していることがわかります。

  ISO 標準の日付と時刻の文字列を取得するには、次のコードを使用します。

  

  以前は 2022 14:44:29 でしたが、現在は UTC 時間 0 タイム ゾーンの 06:44:29 であることがわかります。仕上げる！

RFC 3339

RFCはリクエスト・フォー・コメントの略称です。実際には、番号が付けられた一連のファイルです。この一連のドキュメントには、UNIX や特定のインターネット コミュニティからのソフトウェア ファイルなど、インターネットに関する記事が集められています。RFC には、さまざまなネットワーク プロトコルや、今日説明する時刻形式の標準問題など、インターネット標準に関連する記事も多数含まれています。

RFC3339 この記事の元のタイトルは「インターネット上の日付と時刻: タイムスタンプ (インターネット上の日付と時刻: タイムスタンプ)」で、2002 年 7 月に公開されました。興味のある方は原文を参照してください: https://www.rfc-editor.org/rfc/rfc3339

簡単に言うと、RFC3339 の日付と時刻の定義はより簡潔で、ISO 8601 のいくつかのニッチな表現が削除され、より読みやすくなっています。

RFC3339とISO8601の関係

https://ijmacd.github.io/rfc3339-iso8601/を参照してください。

この Web サイトでは、現在時刻の RFC3339 表現および ISO 8601 表現をリアルタイムで表示できます。下の写真はそのスクリーンショットです。RFC 3339 の表現の一部は ISO 8601 と同じであることがわかります。

よく見ると、RFC3339 形式の日付と時刻の表現は、基本的に最初に表現された時刻を反映できることがわかります。また、ISO 8601 には、2022-242T16:55:17/PT3H のような奇妙な表現が含まれます。

補足: Unix タイムスタンプとうるう秒

Unix タイムスタンプは、1970 年 1 月 1 日 (UTC) からの合計秒数として時間を追跡する方法です。したがって、Unix タイムスタンプは、特定の時点からの秒数のみを表します。また、この合計秒数は、どこにいても技術的には変わらないことに注意することが重要です。したがって、これはコンピュータ システム、クライアントとサーバーの通信、および日付の追跡に非常に役立ちます。

うるう秒の問題については、うるう秒がいつ発生するかは不確実であると以前に述べました。それでは、Unix タイムスタンプのうるう秒をどのように処理すればよいでしょうか? 答えは、時計の速度を遅くすることです。

たとえば、うるう秒は、1997 年 6 月 30 日の 23:59:59 から 1997 年 7 月 1 日の 00:00:00 まで発生する必要があります。

この場合、タイムスタンプ 867715200 は 1997 年 6 月 30 日の 23:59:60 に対応するはずです。しかし、Linux はこのことをまったく知らないようです。これは、Unix タイムスタンプ標準が 1 日を 86400 秒として定義しているためです。Unix に似た解決策は、うるう秒が発生すると ntrp サービスがクロックを遅くすることです。タイムスタンプが 867715199 の場合、さらに 1 秒間この値を維持してから、867715200 を入力します。