新聞を読んだ後、私は2035年頃に私たちの地球上の人々とコンピュータがどうするべきかを自分に尋ねました。時間を1秒後に設定します天文学的な時間に合わせて。
この記事を読んだとき、私は初めてこれがコンピュータに多くの問題を引き起こすと信じていました。戻って既に存在する秒を再生できる時計は、オペレーティングシステムをはじめ多くのプログラムではサポートされません。
しかし、私たちは毎年同様のことをしていることを発見しました。つまり、冬時間を適用するときは、1時間後に戻ります。すべての国が同じかどうかはわかりませんが、夜明けの3時になると、私たちは2時に決めました。
2024-10-27 02:59:59.999999この時間が変更され、タイムスタンプがからに変わると、Linuxオペレーティングシステムはタイムスタンプ付きタスクをどのように管理しますか2024-10-27 02:00:00.000000？たとえば、時間ごとにソートされたすべてのメッセージはなりすまします。
システムタイムスタンプに関する限り、from to（+1）（秒単位）は続行されて2024-10-27 02:59:59.999999いますか？2024-10-27 02:00:00.00000017300699991730070000
この場合、2035年には私たちの時間を1秒短縮する問題と、毎年しているように1時間後に移動する問題は違うのだろうか？たとえば、次のように割り当てることができ
2019682799 = 2034-12-31 23:59.59ます
2019682800 = 2035-01-01 00:00.00。
2019682801 = 2035-01-01 00:00.00
2019682802 = 2035-01-01 00:00.01
しかし、ここで問題は次のとおりです。
正しいオペレーティングシステムを使用しているコンピュータは、変更されていないコンピュータ（古いまたは更新されていないオペレーティングシステム）に遭遇します。
2019682801 = 2035-01-01 00:00.01しかし、2019682802 = 2035-01-01 00:00.02これは本当ではありません。しかし、一部のオペレーティングシステムがまだ存在し、夏時間や冬時間の変更がわからない場合でも、同じ問題が発生します。世界にこのようなコード例はあまりないと思います。
timestamp = System.timeInMillis() millis = millis % 1000 secondsSince1970 = millis / 1000 seconds = secondsSince1970 % 60 minutesSince1970 = ...なぜならここで
seconds二次削除を適用すると、2035年には変数が間違ってしまうからで2019682802はない。0102
答え1
Linuxでは、オペレーティングシステムはデフォルトで夏時間の変更なしにUTC時間で動作する時計を維持します。
（通常）夏時間は1時間で指定されます。時計は変更しませんが、表示時に現地時間に適用されるUTCオフセットを変更します。。
たとえば、中央ヨーロッパのタイムゾーンでは、タイムスタンプ
2024-10-27 02:59:59.999999 UTC+2 = 2024-10-27 00:59:59.999999 UTC = 1730001599
その後にタイムスタンプが表示されます。
2024-10-27 02:00:00.000000 UTC+1 = 2024-10-27 01:00:00.000000 UTC = 1730001600
（ここではPOSIXタイムゾーン指定子を使用しないことに注意してください。POSIX仕様の基盤となるシステムは主にアメリカで開発されており、独自に正の整数タイムゾーン指定子を予約しているため、POSIXタイムゾーンオフセットの符号は次のとおりです。考えるのとは異なる反対の期待は、UTCオフセットの一般的な理解に基づいています。
そのため、プログラムがタイムスタンプを現地時間形式で保存する必要がある場合常にUTCオフセット識別子を含める必要があります。タイムスタンプで。プログラムが夏時間の終わりに人間のレベルのあいまいさを防ぐ必要がある場合は、常にUTCに対応する形式で内部的にタイムスタンプを保存する必要があります。
「UTC時間を1秒後に移動」は、時間スケールに1秒を追加するのと同じです。これは新しいことではありません。、UTCタイムスタンダードにはすでにこれを行う標準的な方法があります。ユンチョ。毎年6月末と12月末（UTC）にうるう秒を挿入する機会があります。
xxxx-12-31 23:59:59 UTC
次は
xxxx-12-31 23:59:60 UTC
その後
(xxxx+1)-01-01 00:00:00 UTC
これが実際に起こるかどうかは、国際機関IERSが決定した地球自転の測定可能な欠陥に依存します。
うるう秒が最後に挿入された時は2016年末でした。
https://hpiers.obspm.fr/eoppc/bul/bulc/UTC-TAI.history
現時点では、2024年6月末にうるう秒を挿入する予定はありません。うるう秒の挿入の次の権威のあるソースはIERS Bulletin Cです。
https://datacenter.iers.org/data/latestVersion/bulletinC.txt
NTP時間同期プロトコルには、この問題を解決するためのうるう秒通知機能があります。 Linuxdateコマンドは、オペレーティングシステムが何が起こっているのかを知っていることを証明するために、適切な時間に23:59:60 UTCタイムスタンプを誠実に表示します。しかし、明らかに、これはすべてのUnixタイムスタンプ秒の長さが同じではないことを意味します。うるう秒が挿入される前に、ほとんどのオペレーティングシステムはUnixタイム秒を2秒の長さと見なします。
（NTPには「負のうるう秒」機能もありますが、これまでは実際に要求されたことがなく、近い将来にも要求されないと予想されます。）
新しい代替実用的なソリューションは次のとおりです。ジャンプスミア：追加の1秒はシステムクロックの速度を遅くして処理されるため、追加の1秒が1日程度かかります。これは、1秒あたりの長さの均一性が+/- 1秒の範囲のタイムスタンプの絶対精度よりも重要であるという考えに基づいています。おそらく、ほとんどの「一般目的」時間目的に有効な解決策でしょう。
うるう秒は、常に1秒未満のタイミング精度または半年以上のすべての時間範囲で正確な秒数を計算する必要がある人にとって問題になります。しかし、これらの正確さを必要とするほとんどの人はすでにこの事実を認識し対処していることがわかりました。
Linux / Unixシステムでこれらの高精度タイミングが必要な場合は、UTCの代わりに国際原子時間（TAI）を展開するためにローカル時刻同期機能（変更されたNTPサーバーなど）を設定できます。その後、システムクロックをUTCの代わりにTAIとして実行し、right/IANA / Olsonタイムゾーンデータベースのタイムゾーンバリアントを使用できます（つまりright/Europe/Paris、Europe/Parisうるう秒を含みます）。
答え2
ここにはすでに良い答えがたくさんありますが、より一般的な事実についての言及はありません。この2番目の変換が発生します。いつもすでにコンピュータにあります。時にはこれらの変換に1秒以上かかることがありますが、大丈夫です。
ご覧のとおり、通常のPC/サーバーのハードウェアクロックは不正確で悪名高いです。時計を頻繁に同期しないと、全体的にドリフトされます。分年間。出典：家庭用コンピューターとサーバーの両方でこの問題を複数回見たり処理したりする必要がありました。
一年中安定した時計を作るのは難しすぎるか、高価なのかはわかりませんが、私の考えではNTPがシンプルで効果的なソリューションなので、より正確なハードウェア時計が必要ないようです。少なくとも通常の状況ではそうではありません。
そして – あなたも気づいたでしょうが – 私たちのすべてのコンピュータはこれに完全に大丈夫です。実際、これはコンピュータの時計を手動で変更することと変わりません。ところで - これは時計を真剣に台無しにするもう一つの作業ですが、何の問題も起こりません。
現実は、ほとんどのプログラムが時計の動きに興味がないということです。安定した単調な時計（フレームに何を描くかを計算するコンピュータゲームなど）が必要な場合は、オペレーティングシステムに別の機能があります。タイムスタンプを返すのではなく、「コンピュータの起動後にナノ秒」などを返します。 2つのイベント間の経過時間を測定するのに適しています。
タイムスタンプは通常、ロギングや精度が重要ではない他の場所に使用されます。実際のミリ秒単位の正確なタイムスタンプが常に必要な場合は非常にまれです。
次に追加：時計が急激に走る別のシナリオを思い出してください。コンピュータがスリープモードまたは休止状態に切り替えられ、再び目が覚めた場合。今これは実際にはい一部のアプリケーションではこれを処理できませんが、それでも非常にまれです。 OSが良いようです。
2を追加します。コア要約 - うるう秒に対するOS/アプリケーションレベルのサポートは関係ありません。重要なのはクロック同期のサポートです。コンピュータが外部タイムソースと時計を正常に同期できる限り、コンピュータは奇妙なことに気づかずにうるう秒を選択します。現在、クロック同期はすべてのデバイスで標準であり、デフォルトで有効になっています。
3つ追加されました：私はこれが決して問題を引き起こさないと言うものではありません。明らかに、これは正しい状況で問題になる可能性があります。実際、これは非常にまれです。
答え3
他の回答に新しい内容を追加することはありませんが、より簡潔で明確に説明しようとします。
タイムゾーン
コンピュータの実際のハードウェア時計は、エポック（1970-01-01 00:00:00 UTC）以降の時間を秒単位で表示します。いくつかのglibcライブラリ（例：strftime(3)）は、特定の時間帯から人が読める時間に変換する方法を知っています。
たとえば、米国/太平洋タイムゾーンでは、次のコマンドを使用して2024年のタイムゾーンの変更を確認できます。zdump注文する:
$ zdump -V -c 2024,2025 US/Pacific
US/Pacific Sun Mar 10 09:59:59 2024 UT = Sun Mar 10 01:59:59 2024 PST isdst=0 gmtoff=-28800
US/Pacific Sun Mar 10 10:00:00 2024 UT = Sun Mar 10 03:00:00 2024 PDT isdst=1 gmtoff=-25200
US/Pacific Sun Nov 3 08:59:59 2024 UT = Sun Nov 3 01:59:59 2024 PDT isdst=1 gmtoff=-25200
US/Pacific Sun Nov 3 09:00:00 2024 UT = Sun Nov 3 01:00:00 2024 PST isdst=0 gmtoff=-28800
したがって、EPOCH以降の秒単位に変換するには、次のコマンドを使用できます。
$ date --date='Sun Mar 10 01:59:59 PST 2024' +%s
1710064799
したがって、この特定の時間（PST）では1710064799エポック（1970-01-01 00:00:00 UTC）から経過した時間（秒単位）。
今回初めて米国/太平洋標準時を確認すると、次のような内容が表示されます。
$ TZ=US/Pacific date --date='@1710064799'
Sun Mar 10 01:59:59 PST 2024
これはまだPST（太平洋標準時）です。しかし、1秒だけ追加すると、次のようになります。
$ TZ=US/Pacific date --date='@1710064800'
Sun Mar 10 03:00:00 PDT 2024
02:00から03:00まで1時間ずつ「ジャンプ」し、時間帯もPST（太平洋標準時）からPDT（太平洋夏時間）に切り替えることが確認できます。ハードウェア時計の秒はまだ同じ方法で実行され、変更されるのは人間の表現（特定の時間帯によって異なります）にすぎません。
ユンチョ
最初に、システムはどのように正確な時間を取得しますか？ネットワークタイム同期プロトコル（NTP）を使用して、一部のタイムサーバー（通常はルーター）で正確な時間をポーリングします。また、ローカルハードウェアクロックとタイムサーバーでポーリングされた時間に差がある場合は、別のアルゴリズムを使用して時刻を同期します。次に、うるう秒を追加または削除することがNTPサーバーの作業です。これを行う方法はいくつかあります。
例えば、Cisco ルータ、月の最後の秒に、うるう秒が追加または削除されます。
vl-7500-6#ディスプレイ時計 2006年12月31日日曜日23:59:59.123 UTC vl-7500-6#ディスプレイ時計 2006年12月31日日曜日23:59:59.627 UTC << 59秒に2回登場 vl-7500-6#ディスプレイ時計 2006年12月31日日曜日23:59:59.131 UTC vl-7500-6#ディスプレイ時計 2006年12月31日日曜日23:59:59.627 UTC
Googleはジャンプスミアつまり、うるう秒の前の最後の日に追加/削除されたうるう秒が24時間の終わりに完全に合計されるまで、毎秒遅くなるか速くなります。
この例では、2022年12月末にうるう秒を想定していますが、実際のスケジュールはまだ発表されていません。
スミア期間は2022-12-31 12:00:00 UTCから始まり、2023-01-01 12:00:00 UTCまで続きます。。この期間の前後の汚れた時計と時間サービスは、うるう秒を適用した時計と一致しています。
スミアプロセスの間、時計は通常より少し遅く実行されます。スミア時間スケールの1秒は約11.6μs長くなります。陸上でSI秒以上を達成しました。
[...]
86,401 SI 秒のスミアリング中に表示された 86,400 秒のストレッチがジャンプに必要な追加 SI 秒に追加されます。
答え4
現地時間は純粋に問題です。プレゼンテーションレイヤー。これは、リモートで最新のシステムのUnix時間または時間データモデルの一部ではありません（最新のWindowsでもハードウェアクロックをUTCに保つことをサポートします）。つまり、イベントは互いに順番に並べられています（うるう秒を処理する特定のモードを除いて、これは困難で議論の余地があります）、各ユーザー（または各プロセス）は独自のアイデアを表示する時間を持つことができます。システムが異なる時間帯にあるか、単に異なる時間帯で作業するか、UTCを使用することを好むユーザーがいるかどうかにかかわらず、異なるポリシーを持つシステム間の時間は、プレゼンテーション層が時間を表示する方法で比較できます。