Unix時間

Unix時間^[a]は、コンピューティングで広く使用されている日付と時刻の表現です。Unixエポックである1970年1月1日00:00:00 UTCから経過したうるう秒数以外の秒数で時間を測定します。現代のコンピューティングでは、マイクロ秒やナノ秒などのより高い粒度で値が格納されることがあります。

Unix 時間は、Unixオペレーティング システムのシステム時間として始まりました。他のコンピュータオペレーティング システム、ファイル システム、プログラミング言語、データベースでも広く使用されるようになりました。

Unix時間は現在、1970年1月1日木曜日の00:00:00 UTCから経過したうるう秒数ではない秒数として定義されており、 Unixエポック と呼ばれています。^{[3] Unix時間は通常、}符号付き整数としてエンコードされます。

Unix時間0は1970年1月1日のUTCの真夜中であり、その後はうるう秒を除いて1秒ごとにUnix時間は1ずつ増加します。たとえば、 1971年1月1日の00:00:00 UTCはUnix時間では次のように表されます。31 536 000。負の値は、それをサポートするシステムでは、Unix エポックより前の時間を示し、エポック前の非閏秒ごとに値が 1 ずつ減少します。たとえば、 1969 年 1 月 1 日の 00:00:00 UTC は、Unix 時間では次のように表されます。−31 536 000。Unix時間における1日は、正確に86400秒。

Unix時間はエポック時間と呼ばれることもあります。これは誤解を招く可能性があります。なぜなら、Unix時間はエポックに基づく唯一の時間システムではなく、Unixエポックは他の時間システムで使用される唯一のエポックではないからです。^[5]

Unix 時間は、うるう秒の扱いにおいて、協定世界時(UTC) および国際原子時(TAI) の両方と異なります。UTC には、原子時計で測定される正確な時間と、太陽に対する地球の位置に関連する太陽時との差を調整するうるう秒が含まれています。国際原子時(TAI) では、毎日が正確に86,400秒の長さで、太陽時間は無視され、地球の自転との同期が1年に約1秒ずつ徐々に失われていきます。Unix時間では、1日には正確に86400秒。各うるう秒は、その直前または直後の秒のタイムスタンプを使用します。 [ 3 ^]

通常のUTC日では、86 400秒後、Unix の時刻番号は真夜中をまたいで連続的に変化します。たとえば、上記の例で使用した 1 日の終わりには、時間表現は次のように進行します。

うるう秒が発生すると、UTCの日付は正確には86 400秒の長さとUnix時間番号（常に正確に1 日の終わりに、平均して約 86,400 秒ずつ増加するうるう秒に不連続が発生します。うるう秒は正または負の場合があります。負のうるう秒が宣言されたことはありませんが、宣言された場合、負のうるう秒の日の終わりに、Unix 時間番号が次の日の初めに 1 ずつ増加します。平均して約 1 年半ごとに発生する、1 日の終わりの正のうるう秒の間、Unix 時間番号はうるう秒の間、次の日まで継続的に増加し、その後、うるう秒の終わりに 1 ずつ戻ります (次の日の初めに戻ります)。たとえば、1998 年末に 厳密に準拠したPOSIX.1システムで発生したのは次のことです。

Unix時間番号は、正のうるう秒の直後の秒で繰り返されます。Unix時間番号したがって、 1 483 228 800はあいまいです。これは、うるう秒の開始 (2016-12-31 23:59:60) または 1 秒後のうるう秒の終了 (2017-01-01 00:00:00) のいずれかを指します。理論上、負のうるう秒が発生した場合、あいまいさは発生しませんが、代わりに、UTC 時間のどの時点も参照しない Unix 時間番号の範囲が存在します。

Unix クロックは、多くの場合、ネットワーク タイム プロトコル(NTP) に関連付けられた異なるタイプの正のうるう秒処理を使用して実装されます。これにより、POSIX 標準に準拠しないシステムが生成されます。詳細については、以下の NTP に関するセクションを参照してください。

UTC うるう秒を含まない期間を扱う場合、2 つの Unix 時間番号の差は、対応する時点間の期間の秒数に等しくなります。これは一般的な計算手法です。ただし、うるう秒が発生する場合、このような計算では間違った答えが出ます。このレベルの精度が要求されるアプリケーションでは、Unix 時間を扱うときにうるう秒の表を参照する必要があり、この問題の影響を受けない別の時間エンコーディングを使用する方が望ましい場合がよくあります。

Unix時間番号は、Unix時間番号の商と剰余をとることで簡単にUTC時間に変換できます。86 400。商はエポックからの日数、剰余はその日の UTC 深夜からの秒数です。正のうるう秒のためにあいまいな Unix 時間番号が与えられた場合、このアルゴリズムはそれを深夜の直後の時刻として解釈します。うるう秒中の時刻を生成することはありません。負のうるう秒のために無効な Unix 時間番号が与えられた場合、同様に無効な UTC 時間を生成します。これらの条件が重要な場合は、うるう秒の表を参照してそれらを検出する必要があります。

一般的に、ミルズスタイルの Unix クロックは、Unix の時刻番号の変更と同期しない閏秒処理で実装されています。時刻番号は、最初は閏秒が発生するはずの場所で減少し、その後、閏秒の 1 秒後に正しい時刻に閏秒が移動します。これにより実装が容易になり、ミルズの論文^[6]で説明されています。正の閏秒が発生すると、次のようになります。

これは、うるう秒の状態変数に注意することで適切にデコードできます。この変数は、うるう秒がすでに実行されたかどうかを明確に示します。状態変数の変化は、うるう秒と同期しています。

負のうるう秒の場合も同様の状況が発生します。この場合、スキップされた秒は少し遅すぎます。システムは、名目上不可能な時間番号を非常に短時間表示しますが、これは TIME_DEL 状態によって検出され、修正できます。

このタイプのシステムでは、Unix 時間番号は両方のタイプのうるう秒に関して POSIX に違反します。うるう秒の状態変数を時間番号とともに収集すると、明確なデコードが可能になり、必要に応じて正しい POSIX 時間番号を生成したり、完全な UTC 時間をより適切な形式で保存したりできます。

このスタイルの Unix クロックに対処するために必要なデコード ロジックは、同じインターフェイスを使用して、仮想の POSIX 準拠クロックも正しくデコードします。これは、挿入されたうるう秒の間ずっと TIME_INS 状態を示し、次の秒の間ずっと TIME_WAIT を示しながら秒数を繰り返すことで実現されます。これには、同期的なうるう秒処理が必要です。これは、基盤となるクロックがうるう秒によって基本的に問題にならない場合に、Unix インターフェイスを介して Unix クロック形式で UTC 時刻を表現する最良の方法でしょう。

Unix の時間管理のもう 1 つの、はるかにまれな非準拠のバリエーションでは、うるう秒を含むすべての秒の値を増分します。^[7]一部の Linux システムはこのように構成されています。^[8]この方法で管理される時間は、「TAI」と呼ばれることがあります (ただし、値が TAI と UTC の差がわかっている時間に対応する場合は、タイムスタンプを UTC に変換できます)。一方、「UTC」と呼ばれることもあります (ただし、うるう秒をカウントしないシステムでは、すべての UTC 時間値が一意の参照を持つわけではありません)。^[8]

TAI にはうるう秒がなく、すべての TAI 日の長さはちょうど 86400 秒であるため、このエンコードは実際には 1970-01-01T00:00:10  TAI から経過した秒数の純粋な線形カウントです。これにより、時間間隔の計算がはるかに簡単になります。これらのシステムの時間値は、厳密に準拠した POSIX システムや NTP 駆動型システムにあるような曖昧さがありません。

これらのシステムでは、UTC と疑似 Unix 時間表現を正しく変換するために、うるう秒の表を参照する必要があります。これは、常用時間との変換にタイム ゾーン表を参照する必要がある方法に似ています。IANAタイム ゾーン データベースにはうるう秒の情報が含まれており、同じソースから入手できるサンプル コードでは、その情報を使用して TAI ベースのタイムスタンプとローカル時間の間で変換します。変換では、1972 年に現在の形式の UTC が開始される前は定義上の問題も発生していました (以下の UTC 基準のセクションを参照)。

このシステムは、表面的には似ているものの、Unix 時間ではありません。POSIX 時間値とは数秒異なる値で時間をエンコードします。エポックが 1970-01-01T00:00:10  TAI ではなく 1970-01-01T00:00:00 TAIであるこのシステムのバージョンが ISO C への組み込みが提案されましたtime.hが、2011 年に承認されたのは UTC 部分のみでした。^[9]ただし、 C tai_clock++20 には存在します。

Unix 時間の数値は、数値を表現できる任意の形式で表現できます。一部のアプリケーションでは、数値は単に 10 進数の文字列としてテキストで表現されるため、追加の問題はほとんどありません。ただし、Unix 時間の特定のバイナリ表現は特に重要です。

time_t多くのプラットフォームでは、時点を表すUnixデータ型は、伝統的に 32ビットの符号付き整数(ただし、下記参照) であり、前のセクションで説明したように Unix 時間番号を直接エンコードします。符号付き 32 ビット値は、1970-01-01 エポックの前後約 68 年間をカバーします。表現可能な最小の日付は 1901-12-13 の金曜日で、表現可能な最大の日付は 2038-01-19 の火曜日です。2038-01-19T03:14:07Z の 1 秒後に、この表現はオーバーフローし、いわゆる2038 年問題が発生します。  

新しいオペレーティング システムの中には、time_tが 64 ビットに拡張されているものもあります。これにより、表現可能な時間が両方向に約2,923 億年に拡張され、これは現在の宇宙の年齢の20 倍以上に相当します。

もともと、 Unix をtime_t符号付きにするか符号なしにするかについては議論がありました。符号なしにすると、将来の範囲が 2 倍になり、32 ビットのオーバーフローが (68 年) 延期されます。ただし、その場合、エポックより前の時間を表すことができなくなります。time_t符号付きにすることが合意されており、これが通常の方法です。QNX オペレーティング システムのバージョン 6 のソフトウェア開発プラットフォームには、符号なしの 32 ビット がありますtime_tが、古いリリースでは符号付きタイプが使用されていました。

POSIXおよびOpen Group Unix 仕様には、ヘッダー ファイルで定義されている時間型と関数を含むC 標準ライブラリが含まれています。ISO C 標準では、 は算術型でなければならないと規定されていますが、特定の型やエンコードは必須ではありません。POSIX では、 は整数型である必要がありますが、符号付きか符号なしかは必須ではありません。 <time.h>time_ttime_t

Unix には、整数でない Unix 時間数値を 2 進小数として直接表現する伝統はありません。代わりに、1 秒未満の精度の時間は、 2 つの整数で構成される複合データ型を使用して表現されます。1 つ目はtime_t(Unix 時間の整数部分)、2 つ目は 100 万分の 1 ( struct timeval) または 10 億分の1 ( struct timespec) 単位の時間数値の小数部分です。^{[10] [11]これらの構造は、} 10 進数ベースの固定小数点データ形式を提供します。これは、一部のアプリケーションでは便利であり、他のアプリケーションでは簡単に変換できます。

閏秒を含む現在の形式の UTC は、1972 年 1 月 1 日からのみ定義されます。それ以前は、1961 年 1 月 1 日から古い形式の UTC が存在し、その形式では、時差が整数でない秒数で区切られるだけでなく、UTC 秒が SI 秒よりわずかに長く、地球の自転を継続的に近似するように定期的に変更されていました。1961 年より前には UTC は存在せず、1958 年より前には原子時計は広く普及していませんでした。これらの時代には、原子時間スケールの代わりに、地球の自転に直接基づくGMTの近似値が使用されていました。 ^{[引用が必要]}

UTC のエンコードとしての Unix 時間の正確な定義は、現在の UTC 形式に適用された場合のみ議論の余地がありません。この形式の UTC の開始前の Unix エポックは、この時代での使用には影響しません。1970 年 1 月 1 日 (Unix エポック) から 1972 年 1 月 1 日 (UTC の開始) までの日数は問題にならず、日数こそが Unix 時間にとって重要なすべてです。

以下のUnix時間値の意味+63 072 000 (つまり、1972 年 1 月 1 日より前) は正確に定義されていません。このような Unix 時間の基準は、UTC の不特定の近似値であると理解するのが最も適切です。その時代のコンピューターには、意味のある 1 秒未満のタイムスタンプを提供できるほど正確に設定されたクロックがほとんどありませんでした。Unix 時間は、1 秒未満の精度を必要とするアプリケーションで 1972 年より前の時間を表すのに適した方法ではありません。このようなアプリケーションでは、少なくとも、使用する UT または GMT の形式を定義する必要があります。

2009年現在^{[アップデート]}、常用時間における閏秒の使用を終了する可能性が検討されています。^[12]この変更を実行する可能性のある方法は、最初はUTCに一致するがその後は閏秒がなく、TAIからのオフセットが一定のままである国際時間^[要出典]と呼ばれる新しい時間スケールを定義することです。これが実現すると、Unix時間は将来的にUTCではなくこの新しい時間スケールで定義される可能性があります。これが起こるかどうかが不確実であるため、将来のUnix時間は今以上に予測可能になります。UTCに閏秒がなくなったとしても、結果は同じです。

Unix時間の初期のバージョンは、 60Hzの速度で増加する32ビットの整数で 、これは初期のUnixシステムのハードウェアのシステムクロックの速度でした。この方法で保存されたタイムスタンプは、2年半強の範囲しか表すことができませんでした。オーバーフローを防ぐために、Unixのリリースごとにカウント元のエポックが変更され、Unixの初期開発では1971年1月1日の真夜中と1972年1月1日がエポックとして使用されました。Unix時間の初期の定義には、タイムゾーンもありませんでした。^{[13] [14]}

現在のエポックである1970年1月1日00:00:00 UTCは、作業に便利な日付であると考えられたため、Unixエンジニアによって任意に選択されました。短期的なオーバーフローを回避するために、精度は秒単位でカウントするように変更されました。^[1]

POSIX.1が書かれたとき、うるう秒をどう正確に定義するかという問題が生じましたtime_t。POSIX 委員会は、Unix 時間を、常用時間との変換の複雑さを犠牲にして、意図どおりにエポックからの秒数を線形にカウントするべきかどうか、または、うるう秒に関する不整合を犠牲にして常用時間の表現にすべきかどうかを検討しました。当時のコンピュータ クロックは、どちらにしても前例になるほど正確に設定されていませんでした。

POSIX 委員会は、ライブラリ関数の複雑さに対する反対意見に影響され、^{[要出典] 、UTC 時間の要素に基づいて Unix 時間を単純な方法で明確に定義しました。この定義は非常に単純であったため、グレゴリオ暦の}閏年規則全体を網羅しておらず、2100 年が閏年になります。

POSIX.1 の 2001 版では、Unix 時間の定義における誤った閏年ルールが修正されましたが、線形時間スケールではなく UTC のエンコードという Unix 時間の基本的な定義は保持されました。1990 年代半ば以降、コンピュータの時計は、これが問題になるのに十分な精度で日常的に設定されており、最も一般的には UTC ベースの Unix 時間の定義を使用して設定されています。これにより、閏秒が発生するたびに Unix 時間番号で手順を実行するために、Unix 実装とネットワーク タイム プロトコルがかなり複雑になりました。^{[引用が必要]}

Unix 時間は、 Unixのシステム時間という本来の用途を超えて、コンピューティングで広く採用されています。 Unix 時間は、 Unix ベースおよび非 Unixオペレーティング システムの両方で提供されるものを含む、ほぼすべてのシステム プログラミングAPIで使用できます。 ほぼすべての最新のプログラミング言語は、 Unix 時間を操作したり、別のデータ構造に変換したりするための API を提供しています。 Unix 時間は、多数のファイル システム、ファイル形式、およびデータベースにタイムスタンプを格納するメカニズムとしても使用されます。

C標準ライブラリは、すべての日付と時刻関数にUnix時間を使用しており、Unix時間はCとC++でタイムスタンプに使用されるデータ型の名前であるtime_tと呼ばれることもあります。CのUnix時間関数は、 POSIX仕様でシステム時間APIとして定義されています。^{[15] C標準ライブラリは、} Microsoft WindowsやmacOSやLinuxなどのUnix系システム を含むすべての最新のデスクトップオペレーティングシステムで広く使用されており、標準プログラミングインターフェイスとなっています。^{[16] [17] [18]}

iOSはSwift APIを提供しており、デフォルトでは2001年1月1日のエポックを使用していますが、Unixタイムスタンプでも使用できます。^[19] Androidはシステム時間APIにタイムゾーンとともにUnix時間を使用します。^[20]

Windowsは内部的に時間を格納するためにUnix時間を使用しませんが、C++で提供され、C標準ライブラリ仕様を実装するシステムAPIでは使用します。^[16] Unix時間は、Windows実行可能ファイルのPE形式で使用されます。 ^[21]

Unix時間は通常、主要なプログラミング言語で利用可能であり、デスクトップ、モバイル、およびWebアプリケーションプログラミングで広く使用されています。Javaは、秒とナノ秒の両方でUnixタイムスタンプを保持するInstantオブジェクトを提供します。^[22] Pythonは、 Unix時間を使用する時間ライブラリを提供します。^[23] JavaScriptは、Unixエポックからのミリ秒単位でタイムスタンプを提供および保存するDateライブラリを提供し、すべての最新のデスクトップおよびモバイルWebブラウザー、およびNode.jsなどのJavaScriptサーバー環境に実装されています。^[24]

Unixベースのオペレーティングシステムで使用するために設計されたファイルシステムは、Unix時間を使用する傾向があります。すべてのAppleデバイスでデフォルトで使用されるファイルシステムであるAPFSと、LinuxおよびAndroidデバイスで広く使用されているext4は、どちらもファイルのタイムスタンプにナノ秒単位のUnix時間を使用します。^{[25] [26]} RARやtarなど、いくつかのアーカイブファイル形式では、タイムスタンプをUnix時間で保存できます。^{[27] [28] Unix時間は、} MySQLやPostgreSQLなどのデータベースにタイムスタンプを保存するためにもよく使用されます。^{[29] [30]}

Unix 時間は、カレンダーの日付と時刻をコンパクトな形式でエンコードし、コンピュータ内部で使用するために設計されました。人間が簡単に読み取ったり、タイムゾーンに依存する値を保存したりすることを意図したものではありません。また、デフォルトでは時間を秒単位で表すように制限されているため、プログラムの実行時間を測定するなど、より正確な時間測定が必要な場合には適していません。^[31]

Unix 時間は設計上、保存に特定のサイズを必要としませんが、Unix 時間の最も一般的な実装では、基盤となるハードウェアのワード サイズと同じサイズの符号付き整数を使用します。最近のコンピューターの大部分は32 ビットまたは64 ビットであり、多数のプログラムが依然として 32 ビット互換モードで記述されているため、Unix 時間を使用する多くのプログラムは符号付き 32 ビット整数フィールドを使用していることになります。符号付き 32 ビット整数の最大値は2 ³¹ − 1で、最小値は−2 ³¹であるため、1901 年 12 月 13 日 (20:45:52 UTC) より前、または 2038 年 1 月 19 日 (03:14:07 UTC) より後の日付を表すことはできません。早期の打ち切りは、履歴情報を保存しているデータベースに影響を及ぼす可能性があります。タイムスタンプに32ビットのUnix時間が使用されている一部のデータベースでは、1901年より前の日付を表すために、文字列などの別の形式のフィールドに時間を格納する必要がある場合があります。遅いカットオフは2038年問題として知られており、日付が近づくにつれて問題を引き起こす可能性があります。2038年のカットオフを超える日付は、1901年の表現可能な範囲の開始点に戻るためです。^{[31] : 60}

64ビットのUnix時間表現では日付範囲のカットオフは問題にならない。符号付き64ビット整数で保存されたUnix時間で表現できる日付の有効範囲は5840億年以上、1970年を基準として両方向に2920億年である。^{[31] : 60-61  [32]}

Unix時間は、エポックからカウントする唯一の標準時間ではありません。Windowsでは、この型は、1601年1月1日0:00 GMTFILETIMEから経過した100ナノ秒間隔のカウントとして時間を保存します。^{[33] Windowsエポック時間は、ファイル[34]のタイムスタンプを保存するためや、} Active Directoryタイムサービス^[35]やサーバーメッセージブロックなどのプロトコルで使用されます。

コンピュータ間の時間調整に使用されるネットワークタイムプロトコルは、1900年1月1日をエポックとして、秒を符号なし32ビット整数で、小数秒を符号なし32ビット整数でカウントし、232^秒ごとに（約136年に1回）ロールオーバーします。^[36]

多くのアプリケーションやプログラミング言語は、明示的なタイムゾーンで時間を保存する方法を提供しています。^{[37]また、} ISO 8601など、人間とコンピュータの両方が読み取れる時間形式の標準も数多く存在します。

Unix 愛好家は、Unix 時刻の重要な値を祝うために「time_t パーティー」（「タイムティー パーティー」と発音）を開催してきた歴史があります。 ^{[38] [39]これは、多くのカレンダーで年が変わるときに行われる}新年のお祝いに直接似ています。Unix 時刻の使用が広まるにつれて、その節目を祝う習慣も広まりました。通常、10 進数の丸い数値である時刻値が祝われ、10 進数で値を表示する Unix の慣例に従いますtime_t。一部のグループでは、2004 年 1 月 10 日土曜日の 13:37:04 UTC に発生した+2 ³⁰などの丸い2進数も祝われます。 ^{[引用が必要]}

これらが祝うイベントは、通常、「 Unix エポックからのN秒」と説明されますが、これは正確ではありません。上で説明したように、Unix 時間でのうるう秒の処理により、Unix エポックからの経過秒数は、エポック以降の時間の Unix 時間数よりもわずかに大きくなります。

• 1973 年 10 月 17 日水曜日の 18:36:57 UTC に、 Unix 時間の数字 (119731017) 内にISO 8601形式^[b] (1973-10-17)の日付が初めて出現しました。
• 2001年9月9日日曜日の01:46:40 UTCに、Unixビレニアム（Unix時間番号1000 000 000）が祝われた。^[40]ビレニアムという名前は、 billion（十億）とmillennium （千年紀）を組み合わせた造語である。^{[41] [42]}テキスト表現を使用してタイムスタンプを保存する一部のプログラムでは、テキストソートのようにソートエラーが発生し、売上高の1桁で始まる時間が、 9桁で始まるそれ以前の時間の前に誤ってソートされた。影響を受けたプログラムには、人気のあるUsenetリーダーKNodeや、KDEデスクトップ環境の一部である電子メールクライアントKMailなどがあった。このようなバグは一般に表面的な性質のものであり、問​​題が明らかになるとすぐに修正された。^{[要出典]この問題は、} WordPerfectのLinuxバージョンで提供される多くのFiltrixドキュメント形式フィルターにも影響を及ぼした。Corelはもはやそのバージョンのプログラムを販売またはサポートしていないため、ユーザーコミュニティによってこの問題を解決するためのパッチが作成された。 ^[43]
• 2009年2月13日金曜日23時31分30秒UTCに、Unix時間の10進表現は1 234 567 890秒。^[44] GoogleはこれをGoogle Doodleで祝いました。^[45]世界中のさまざまな技術サブカルチャーの間で、この記録を祝うパーティーやその他のお祝いが開催されました。1 234 567 890秒。^{[38] [46]}

ヴァーナー・ヴィンジの小説『天空の奥深く』は、数千年後の未来で、いまだに Unix エポックを使用している宇宙貿易文明を描いている。成熟したコンピュータ システムで使用可能なコードを発見し、維持する責任を持つ「プログラマー兼考古学者」は、当初、そのエポックとは人類が初めて月面を歩いたときのことだと信じていたが、その後、それが「人類初のコンピュータ オペレーティング システムの 1 つにおける 0 秒」であることに気付く。^[47]

• エポック（コンピューティング）
• システム時間

Wikiversity にはJavaScript/エポックタイムコンバーターに関する学習リソースがあります

• Unix プログラマーズ マニュアル、初版
• Landon Curt Nollによる POSIX の決定に関する個人的な説明
• chrono 互換の低レベル日付アルゴリズム – グレゴリオ暦とユリウス暦の日付と Unix 時間の開始からの日数を変換するアルゴリズム