開発者ツール · Unix タイムスタンプ コンバータ
うるう秒と Unix 時間: エポックが存在しないふりをする理由
· 背景
タイムスタンプ unix-time タイムゾーン
UTC では、1972 以降、うるう秒が挿入されていますが、Unix 時間では単にうるう秒がカウントされません。これは、一部の秒が 2 回発生したことを意味します。この投稿では、その理由、スメアリングとは何か、そしてなぜこの慣習全体が終了する予定なのかについて説明します。
2 回発生した 2 回目 — 1 つのシステムで 23:59:60 が発生し、別のシステムで 23:59:59 が繰り返され、深夜に重複キー エラーが発生しました
ToolAcre は、`23:59:60` で終わる ISO 行を生成できません。そのテストでは、うるう秒境界に名前を付け、1 つのエポック値が `2016-12-31T23:59:59.000Z` としてフォーマットされ、次のエポック値が `2017-01-01T00:00:00.000Z` としてフォーマットされることが期待されます。それらの間に表示可能な余分な秒はありません。
この事実は、外部ソースが別の規則を使用しているログに影響を与える可能性がありますが、このリポジトリには重複キー インシデントの証拠は含まれていません。システム内に繰り返しラベルが表示される場合は、自動的にコンバータのせいにするのではなく、そのクロックとストレージ パスを検査してください。
したがって、物理秒ごとに一意のラベルを必要とするシステムには、この Unix から日付へのマッピングよりも多くのコンテキストが必要です。コンバータは、そのモデルが省略しているラベルを製造できません。
ToolAcre は表現可能なものではないことを証明します 23:59:60;合鍵事件は文書化されていない
概要では、原子時間、地球の自転、および許容しきい値について説明しました。これらの科学的および標準的な主張は、タイムスタンプ コードやテストによって確立されたものではありません。それらは記憶から言い換えるのではなく、意図的に省略されています。ここでのメカニズムは、世界的な計時政策の背後にある理由を証明するものではありません。
このルートを使用する場合、必要な証拠はより単純です。日付と ISO 出力は通常の 2 番目のラベルを公開し、POSIX スタイルのエポックはテストされた境界を越えて進みます。うるう秒ガバナンスをソースから扱うには、許可されたリポジトリ パスを超えた信頼できる資料が必要になります。
この境界は回避的ではなく明示的です。ソフトウェア テストは表現に関する質問に答えますが、科学史にはその目的のために書かれ、独自の条件でレビューされる資料が必要です。
うるう秒の物理的根拠には、このリポジトリ外のソースが必要です
実装されたモデルは、軸上の市民日が 86,400 番号の Unix 秒であるかのように動作します。 2016 年の境界をまたぐ場合も含め、連続する整数入力は 1 秒異なります。 `fromEpoch` はそれぞれに 1,000 を乗算し、結果のミリ秒カウントを日付形式に設定します。
これを「無視する」うるう秒を呼び出すと、観測可能な出力が説明されます。固有の Unix 値は `:60` ラベルにマップされません。これは、実際の挿入中にすべてのマシン クロックが同じように進むことを意味するものではありません。コンバーターはカウントを受け入れます。ホストクロックのサンプリングや制御は行いません。
より大きな範囲にわたる算術演算は同じ規則に従うため、2 つの Unix 値を減算することで、省略されたリープ ラベルを再構築するのではなく、POSIX スタイルのカウントの差が測定されます。
テストされた変換には、連続するエポック値の間にうるう秒ラベルがありません
システムはステップ、リピート、またはスミアを適用できますが、リポジトリは、どのプロバイダーがどのメソッドを、どの間隔で、またはどのような式で使用するかを識別しません。直接的な証拠なしにこれらの詳細を公開すると、運用上危険な精度が生じます。したがって、この記事ではプラットフォーム固有のクロックについて約束するものではありません。
うるう境界付近のイベントが重要な場合は、ソースのクロック ドキュメントと生の値を保存します。処理が異なる 2 つのシステムは、両方の値が UTC としてフォーマットされた後でも一致しない可能性があります。変換だけでは、サンプリング動作を調整したり、省略されたスケールの区別を回復したりすることはできません。
ランタイムの選択は、イベント周辺の短期間の順序付けにも影響を与える可能性があります。操作上その区別が重要な場合は、単調カウンタまたはソース固有のシーケンス データを保存します。
クロックステップとスミアの動作はプラットフォーム固有であり、ここでは未検証です
1,483,228,799 秒を入力します。検証された ISO 結果は `2016-12-31T23:59:59.000Z` です。入力を 1,483,228,800 まで 1 回インクリメントします。結果は `2017-01-01T00:00:00.000Z` になります。整数を減算すると 1 が得られ、このモデルで表示されている進行と一致します。
ローカル行には、ブラウザーによって異なる日付またはオフセットが表示される場合がありますが、それらは同じ瞬間から派生したものです。境界チェックには ISO 行を使用します。ローカル ゾーンの変更は、うるう秒ラベルが存在するかどうかとは無関係です。
ISO 文字列にはロケールの依存性がないため、このペアは有用な回帰テストです。関連するエッジでコンバータの動作を直接ロックします。
動作例: リポジトリのテスト済み 2016 境界
ワークブックは 2022 解決策と将来の期限を参照していました。実装の証拠には基準や政策のソースは含まれていないため、ここでは日付も予測も主張しません。計時ポリシーは変更される可能性があるため、発行時点で最新の信頼できる引用に値します。
その主張を省略しても、ソフトウェアのガイダンスが弱くなるわけではありません。既存のデータについては、スケール、単位、クロック ソースを文書化する必要があります。コンバーターの現在の動作は、将来の民間時の慣行に関する決定とは関係なく、引き続きテスト可能です。
メンテナは、解決策を直接引用することで、後でポリシー コンテキストを追加できます。それまでは、サポートされていない将来の保証を公表するよりも、期限を除外する方が正確です。
将来の政策決定は信頼できる情報源がない限り省略されています
TAI、GPS、その他のスケールは時間を異なる方法で表すことができますが、ToolAcre にはそれらのセレクターやオフセット テーブルが提供されていません。このようなカウントを Unix 秒として貼り付けると、1970 POSIX スタイルの解釈が適用されるだけです。読み取れる結果であっても、意味的に間違っている可能性があります。
関連する瞬間の原点と関係を定義するソースを使用して他のスケールを変換し、結果の Unix 値を検査します。記憶されている定数を追加しないでください。リープ履歴を含む関係は、まさにソースのない演算が脆弱になる場所です。
モードがないことは、UI の 3 つの単位オプションで確認できます。時間スケールを変更するものはありません。自動は 2 つの Unix 解像度の中から選択するだけです。
他の時間スケールは、この Unix コンバータの実装の範囲外です
このコンバーターの場合、検証されたルールは、テストされた境界における 23:59:59 から 00:00:00 までの直接のステップです。このモデルは通常のエポック演算をサポートしており、`:60` 出力が表示されない理由を説明しています。実際の境界を通過する間にオペレーティング システムのクロックがどのように動作するかを保証するものではありません。
リープ処理に近い精度が重要な場合、変換は証拠ソースではなく、プレゼンテーションの最後のステップです。まず、クロックスケールのドキュメント、同期動作、生のイベントフィールドを収集します。 ToolAcre は、テストされたモデルで宣言された Unix カウントが何を意味するかを表示できます。
飛躍境界から離れた通常のログの場合、このニュアンスは表示を変更することはほとんどありません。ただし、機密境界付近では、モデルに名前を付けることで、物理秒の忠実度の誤った主張を防ぐことができます。