web-dev-qa-db-ja.com

Unix時間/公式時間はどこで測定されますか？

免責事項：

StackExchangeサイトのリストを20分ほど読み、これを投稿する場所を見つけようとしました。より適切なサイトを知っている場合は、この質問をそこに移動してください。これを投稿しているのは、Unixの時間が考えられたからです。

私たち皆が知っているように、UNIXの時間とUTCがあります。 Unixの時間は刻々と刻々と秒を数え続けます（1秒あたり1秒）。一方、UTCは、人間の読み取り可能な形式で時間を維持しようとしますが、その回転は地球の位相に合わせて調整されます。これを行うために、UTCは時々うるう秒を挿入します。

時間は、物体が経験している物体が受ける重力、他の種類の加速度、および相対速度に比例するため、2つの質問が生じます。最初に簡単なものを乗り越えましょう：UNIX時間はどこで測定されますか？アリスとボブが同じ場所にいるとき、現在の時刻が1467932496.42732894722748であることに同意し始めた場合（1秒はもちろん、セシウム133の2つのエネルギーレベル間の遷移に対応する9'192'631'770の放射サイクルとして定義されます） atom安静時と0 K）、海面に住んでいるアリスと山の高いところに住んでいるボブ、または北極に住んでいるアリスと赤道に住んでいるボブによる双子のパラドックスを体験してください、彼らはもう同意しません。それでは、UNIX時間はどのように正確に定義されますか？

地球が軌道を完了したときに誰もが確実に同意できるため、最初はUTCの問題に気付かない可能性があります（もちろん、これは大陸プレートの動きを無視していますが、GPSを使用するとその動きを測定できるため、かなりよく理解できたと思います非常に正確に、それらがモデルの設定された位置にあり、大陸プレートが移動しても移動しないと想定できます）。それらが山、海面、赤道、または北極にあるかどうかは関係ありません。時差があるかもしれませんが、蓄積されません。

しかし、1秒は、セシウム133の2つのエネルギーレベル間の遷移に対応する9'192'631'770サイクルの放射線として定義されますatom静止時および0 Kおよびセシウム133 = atom地球の軌道は関係ありません。UTCはうるう秒を挿入する場所を決定しますが、地球の軌道の位相と測定時間の間に測定または予測されたシフトが必要ですどこかに原子時計によって。どこにあるの？

timestampstime
21
UTF-8

あなたの見出しの質問には本当の答えはありません。 Unix時間は実際のタイムスケールではなく、どこでも「測定」されません。 UTCには表現できない瞬間があるので、UTCの表現です。 Unixの時間は、毎日86,400秒であることを主張していますが、うるう秒のためにUTCはそれからずれています。

幅広い質問については、4つの重要なタイムスケールがあります。

  1. T1 （世界時）。これは、恒星に対する地球の回転を測定する世界中の観測所によって計算されます。これらの観測と簡単な計算により、グリニッジの王立天文台での正午の瞬間に基づいた古いグリニッジ標準時のより近代的なバージョンが得られます。世界時は [〜＃〜] iers [〜＃〜] （国際地球回転および参照システムサービス、以前は国際地球回転サービス）と呼ばれる組織によって計算されます。

  2. [〜＃〜] tai [〜＃〜] （国際原子時間）。世界中の何百もの原子時計が保持しており、国家標準化団体などによって維持されています。 TAIに寄与するクロックのキーパーは、クロックを互いに向けて、個々のクロックの小さなエラーをキャンセルし、アンサンブル時間を作成する time transfer テクニックを使用します。そのアンサンブルはTAIであり、SI単位系のスチュワードである国際計量測定局（BIPM）によって発行されています。時間拡張に関する質問に答えるために、TAIは原子時間海面で（実際には、同じアイデアのより洗練されたバージョンであるジオイドで）として定義されており、各クロックは影響を修正しますそれ自身の高度の。

  3. [〜＃〜] utc [〜＃〜] （協定世界時）。 1972年1月1日のUTCはTAIより10秒遅れて設定されており、その日付以降、うるう秒が加算または減算された場合を除き、TACとまったく同じレートでカチカチと進みます。 IERSは、差を0.9秒以内（実際には約0.6秒以内）に保つために、うるう秒をアナウンスすることを決定します。うるう秒が追加されると、差が-0.6から+0.4になります。理論的には、うるう秒は正と負の両方になる可能性がありますが、SIとTAIによって確立された基準と比較して地球の回転が遅くなっているため、負のうるう秒は必要ではなく、おそらく必要ありません。

  4. UTCを単一の数値として表現するために最善を尽くすUnix時間。 86,400の倍数であるすべてのUnix時間は、真夜中のUTCに対応します。すべてのUTC日が86,400秒であるわけではなく、すべての「Unix日」がそうであるので、なんとかしてパッチを適用しなければならない矛盾する違いがあります。うるう秒に対応するUnix時間はありません。実際には、システムは前の秒が2回発生したかのように動作し（UNIXタイムスタンプが1秒後ろにジャンプしてから、次に進みます）、または leap smearing のような手法を適用して、時間をより長くワープしますうるう秒の両側の期間。どちらの場合も、少なくとも2番目は単調ですが、不正確さがいくつかあります。どちらの場合も、2つの離れたUnixタイムスタンプaとbの間で経過する時間は、b-aと等しくありません。これは、b-a 間に介在するうるう秒の数と等しくなります。

UT1、TAI、UTC、およびIERSはすべて世界規模の多国籍の取り組みであるため、単一の「場所」はありませんが、IERSの速報はパリ天文台から発行され、BIPMもパリに拠点を置いていますが、これは1つの答えです。正確で追跡可能な時間を必要とする組織は、タイムベースを「UTC（USNO）」のようなものとして述べる可能性があります。これは、タイムスタンプがUTCであり、それらが米国海軍天文台の時間から導出されることを意味しますが、私はUnix時間について述べましたが、基本的にそのレベルの精度と互換性がありません。本当に正確な時間を扱う人は、Unix時間に代わるものがあります。

30
hobbs

時計の調整は、IERSによって調整されます。必要に応じて、うるう秒のタイムストリームへの挿入をスケジュールします。

から The NTP Timescale and Leap Seconds

パリ天文台の 国際地球回転サービス （IERS）は、USNOおよび他の観測所が提供する天文観測を使用して、地球回転の不規則な変動を修正したUT1（ナビゲーター）タイムスケールを決定します。

私の知る限り、23：59：60（うるう秒）と翌日の00:00:00は、Unix Timeでは同じ秒と見なされます。

12
BillThor

UNIX時間は、UNIXを実行しているコンピュータで測定されます。

この答えは、Coordinated Universal Time（UTC）、International Atomic Time（TAI）、およびSI秒が何であるかを知っていることを期待します。それらを説明することはかなり超えて UnixおよびLinux Stack Exchangeの範囲です。 これはありません物理学または天文学のスタック交換。

ハードウェア

コンピューターには、クロックとタイマーを駆動するさまざまな発振器が含まれています。それが持っているものは、そのアーキテクチャに応じてコンピュータごとに異なります。しかし、通常、そして非常に一般的な用語で：

  • プログラム可能なインターバルタイマー（PIT）がどこかにあります。これは、特定の数の発振をカウントし、中央処理装置への割り込みをトリガーするようにプログラムできます。
  • 中央プロセッサにはサイクルカウンターがあり、実行される各命令サイクルごとに1をカウントします。

非常に広義の操作理論

オペレーティングシステムカーネルは、PITを使用してticksを生成します。これは、PITをフリーランに設定し、たとえば100分の1秒の間隔で適切な振動数をカウントし、割り込みを生成してから、カウントを自動的にリセットして再度実行します。これにはバリエーションがありますが、本質的にはこれによりtick割り込みが一定の頻度で発生します。

ソフトウェアでは、カーネルはティックごとにカウンターをインクリメントします。それはそもそもPITをプログラムしたので、ティック周波数を知っています。つまり、1秒を構成するティックの数がわかります。これを使用して、秒をカウントするカウンターをいつインクリメントするかを知ることができます。この後者は、カーネルの「UNIX時間」の考え方です。実際、独自のデバイスに委ねられている場合は、SI秒あたり1の割合で単純にカウントアップします。

これを複雑にする4つのことが、これを非常に一般的な用語で説明します。

ハードウェアは完璧ではありません。データシートに、発振器周波数が[〜＃〜] n [〜＃〜]ヘルツであると記載されているPITは、代わりに（たとえば）[〜＃〜]の周波数を持つ可能性がありますn [〜＃〜]。00002ヘルツ、明らかな結果。

このスキームは、CPUが1秒間に何百回も起動して、変数の数値をインクリメントする以外の処理を行わないため、電源管理との相互運用性が非常に低くなっています。そのため、一部のオペレーティングシステムには、「ティックレス」デザインと呼ばれるものがあります。カーネルは、ティックごとにPITが割り込みを送信するのではなく、（低レベルのスケジューラーから）スレッドクォンタが不足しない状態でいくつのティックが通過するかを計算し、PITがそのティック数をカウントするようにプログラムします。ティック割り込みを発行する前の未来。次に、次のティック割り込みで[〜＃〜] n [〜＃〜]ティックの経過を1ティックではなく記録する必要があることを認識しています。

アプリケーションソフトウェアには、カーネルの現在時刻を変更する機能があります。 step値にすることも、slew値にすることもできます。旋回では、秒カウンターをインクリメントするために経過する必要があるティックの数を調整します。したがって、完全なオシレータを想定している場合でも、秒カウンタは必ずしもSI秒あたり1のレートでカウントされるわけではありませんとにかく。ステッピングでは、秒数カウンターに新しい数値を書き込むだけです。これは通常、最後の1秒がチェックされてから1 SI秒まで発生しません。

最近のカーネルは、秒だけでなくナノ秒もカウントします。しかし、それはばかげており、多くの場合、ナノ秒に1回のティック割り込みを実行することはまったく不可能です。ここで、サイクルカウンターなどが機能します。カーネルは毎秒（または各ティック）のサイクルカウンター値を記憶し、何かがナノ秒単位の時間を知りたいときに、カウンターのcurrentカウンター値から計算できます。最後の1秒（またはティック）からの経過時間。ただし、繰り返しになりますが、命令サイクルの周波数が変化する可能性があるため、電力と熱の管理がこれに悪影響を及ぼし、カーネルは（たとえば）高精度イベントタイマー（HPET）などの追加ハードウェアに依存するようなことを行います。

C言語とPOSIX

C言語の標準ライブラリは、不透明な型、time_t、さまざまなフィールドが指定された構造型tm、およびtime()、mktime()などのさまざまなライブラリ関数の観点から時間を記述します、およびlocaltime()。

簡単に言うと、C言語itselfは、time_tが利用可能なデータ型の1つであるnumericであり、時間差を計算する唯一の信頼できる方法がdifftime() 関数。 time_tが実際にinteger型の1つであり、-エポックからの秒数をカウントすることをより厳密に保証するのは、POSIX標準です。 timespec構造体タイプを指定するのはPOSIX標準でもあります。

time()関数は、システムコールとして説明されることがあります。実際、これは、多くのシステムで、かなり長い間、今日では基本的なシステムコールではありませんでした。たとえば、FreeBSDでは、基礎となるシステムコールはclock_gettime()であり、秒または秒+ナノ秒でさまざまな方法で測定できるさまざまな「クロック」が利用できます。アプリケーションソフトウェアがカーネルからUNIX時間を読み取るのは、このシステムコールです。 （一致するclock_settime()システムコールにより、それらをステップ実行することができ、adjtime()システムコールにより、スルーすることができます。）

多くの人々がPOSIX標準を揺さぶって、それが規定するものについて非常に明確で正確な主張をしています。そのような人々は、たいていの場合、実際にはそうではありませんread POSIX標準。その根拠が示すように、標準が使用する語句である「エポックからの秒数」をカウントするという考え意図的には、POSIX秒がSI秒と同じ長さであることを指定していません。 gmtime()の結果は「その外観にもかかわらず、必然的にUTC」であることがわかります。 POSIX標準は意図的に十分に緩いので、（たとえば）管理者がうるう秒の調整を行ってから1週間後にクロックを再設定することにより、手動でうるう秒の調整を修正できます。確かに、理論的根拠は、時計故意に間違って設定されているを現在のUTC時間以外の時間に合わせるシステムに対応するのに十分に緩いことを指摘しています。

UTCおよびTAI

カーネルから取得されるUNIX Timeの解釈は、アプリケーションで実行されるライブラリルーチン次第です。 POSIXは、カーネルの時間とstruct tmの「壊れた時間」の間の同一性を指定します。しかし、ダニエルJ.バーンスタインがかつて指摘したように、標準の1997年版はこのアイデンティティをひどく間違っており、グレゴリオ暦のうるう年の規則（小学生が学ぶ何か）を台無しにして、2100年以降は計算に誤りがありました。 「違反のほうが遵守よりも名誉がある」とは、すぐに思い浮かぶ言葉です。

そして確かにそうです。現在、いくつかのシステムは、この解釈をアーサーデビッドオルソンが作成したライブラリルーチンに基づいています。このルーチンは、通常、/usr/share/zoneinfo/の下のデータベースファイルにエンコードされた悪名高い "オルソンタイムゾーンデータベース"を参照します。 Olsonシステムには2つのモードがあります。

  • カーネルの「エポックからの秒数」は、うるう秒を除いて、1970-01-01 00:00:00 UTC以降のUTC秒をカウントすると見なされます。これは、Olsonタイムゾーンデータベースファイルのposix/セットを使用します。すべての日には86400カーネル秒があり、1分には61秒はありませんが、常にSI秒の長さであるとは限らず、うるう秒が発生したときにカーネルクロックが回転またはステップする必要があります。
  • カーネルの「エポックからの秒数」は、1970-01-01 00:00:10 TAIからのTAI秒をカウントすると見なされます。これは、Olsonタイムゾーンデータベースファイルのright/セットを使用します。カーネル秒は1 SI秒の長さであり、カーネルクロックはうるう秒を調整するためにスルーまたはステッピングを必要としませんが、ブレークダウンタイムは23:59:60などの値を持ち、日数は常に86400カーネル秒であるとは限りません。

M.バーンスタインは、daemontoolsツールセットを含むいくつかのツールを作成しました。これらのツールセットは、right/を必要とし、1970-01-01 00:00:00 TAIからTAI秒を取得するために単にtime_tに10を追加しました。彼はこれをマニュアルページに文書化しました。

この要件は（おそらく無意識のうちに）daemontools-encoreやrunitなどのツールセットとFelix von Leitnerのlibowfatによって継承されました。 Olson posix/で Bernstein multilog 、 Guenter multilog 、または Pape svlogd を使用しますたとえば、構成とすべてのTAI64Nタイムスタンプは、（これを書いている時点では）1970-01-01 00:00:10 TAIからactual TAI秒カウントより26秒遅れています。

Laurent Bercotと私は、s6とnoshでこれに対処しましたが、異なるアプローチをとっていました。 M. Bercotの tai_from_sysclock() はコンパイル時のフラグに依存しています。 TAI64Nを扱うnoshツールは、TZおよびTZDIR環境変数を調べて、posix/およびright/を自動検出します（可能な場合）。

興味深いことに、FreeBSDはtime2posix()およびposix2time()関数をドキュメント化しており、Olsonのright/モードと同等の、time_tをTAI秒として使用できるようにしています。ただし、有効になっていないようです。

もう一度…

UNIX時間は、UNIXを実行しているコンピューター上で、コンピューターのハードウェアに含まれている発振器によって測定されます。 SI秒は使用しません。表面的には似ているかもしれませんが、それはUTCではありません。そしてそれ意図的にはあなたの時計が間違っていることを許します。

参考文献

9
JdeBP