Java 7で国際原子時計を取得する方法

Question

私はJava7プロジェクトで作業しており、国際原子時計ではタイムスタンプが必要です。しかし、私は苦労してる

How to get GPS Time and TAI time in Java?

http://www.coderanch.com/t/549178/java/java/TAI-Atomic-Time-International

：私は、JSR-310および（JSR-310を実装している）ThreeTenプロジェクトに、この、その点に関連するいくつかの他の質問を見つけましたJava 7に何を使用するか、どこから入手するかを正確に検討してください。 ThreeTen用のGitHubページ、OpenJDKページなど、古いSourceForgeのようです。&

私はJava 7バックポートを見つけましたが、これをMavenからダウンロードした後、実際に必要なTAIInstantクラスは含まれていません（TIAInstantクラスはjavax.timeのThreeTen SourceForge JavaDocにリストされています）。 .TAIInstant）。完全のために

、これは私のpom.xmlからの抜粋です：

<dependency> 
    <groupId>org.threeten</groupId> 
    <artifactId>threetenbp</artifactId> 
    <version>0.8.1</version> 
</dependency> 

私は何か他のものを使用する必要があり、どこからそれを取得する必要がありますか？

注：申し訳ありませんが、私が言及しているすべてのページへのリンクを提供することができません、StackOverflowは、より高い担当者なしで投稿あたり2以上のリンクを持つことはできません。

[EDIT] TAIを望む理由はそれ が飛躍気にしないので、私は、私はTAIも正&負のうるう秒の両方の間に（満たして信じて単調に増加しているタイムスタンプを、必要があるということです 秒 は、すべての秒を均等にカウントします（うるう秒も含みます）。

さまざまなソースからPOSIX/Unixの時間を読んだところ、うるう秒以上のUnix Timeで何が起こっているのかはまだ分かりません。 Unix TimeはUTC Timeを参照する点ではあいまいですが、うるう秒が発生した瞬間にUnix Timeで何が起きるのかは不明です。 Unix Timeは「一時停止」するか、たとえば後方に移動しますか？そしてもっと重要なのは、たとえUnix Timeの仕様に従ってはならないとしても、Unixの実装は実際にうるう秒に関する仕様に従っているのだろうか？

最後に、System.currentTimeMillis（）はPOSIX Time（秒よりもむしろミリ秒ではありますが）に相当すると言っていますか？

注意、JVMとマシン間で移植可能なオブジェクトが必要です（System.nanoTime（）などを除く）。すなわち -

[結論]

TAI
TAIは、毎秒をカウントし、 'すべての秒が等しい' ている時間を測定するシステムです。 1秒ごとに同じ期間が構成され、すべての秒（閏秒を含む）が合計でカウントされます。これは、TAIの任意の開始点から数えた秒数（Unix Epochなど）が単調に増加する整数であることを意味します。

POSIX時間はPOSIXタイムの時間を測定するための標準（NOT実装）です。毎日正確に86400秒と定義しています。したがって、POSIX時間は閏秒をカウントしません（時には1分が61秒を超え、86400秒を超える日につながり、理論的には1分が59秒になり、< 86400秒の日数になります）。これは、POSIXの '秒'には可変長があり、閏秒の直前/直後/後にPOSIXクロックが秒をスキップするか、またはそれらを繰り返すことを意味します。具体的には、Meno Hochschildによって参照されているPOSIX仕様では、「実際の時刻と、Epochからの秒の現在の値との関係は不明です。

UTC
UTCは、太陽の位置及び（閾値以内）時刻との間の関係を維持することを目指し、地球が太陽の周りを移動する方法に関連する時間基準です。つまり、地球のUTC + 0地域では、太陽は常に正午UTC時に最高です。地球の回転速度は固定されておらず、予測可能な方法で変動しない（閏秒がいつ必要になるかを予測することができないか、閏秒が正かどうか、

時間を表す負のうるう秒）
TAIとPOSIXの両方が、「秒のカウント」の表現があるように私には思える（すなわち、実際に店舗へのコンピュータのための簡単なもの）、UTCは「人間であるのに対し通常はコンピュータによって内部的に記憶されていない時間（すなわち、年/月/日時：分：秒。ミリ秒）の「解釈」である。

翻訳タイムズ
上記を考えると、（カウントうるう秒と）TAIにPOSIX（カウントされたうるう秒無し）から翻訳する多くの問題があります。

1. それはテーブルを維持することが必要です/ POSIX時間をTAI時間に変換するためのうるう秒の数
2. ポイント1が処理されても、上記のようなPOSIX仕様では何が起こるかについての保証はありません中にうるう秒があるので、正確に言及する方法
3. 明確な時間をntingすることはシステムの数は、それらの間のタイムスタンプを渡し、通信する必要がある場合、我々はうるう秒のテーブル/カウントは一方

一貫性が保たれることを保証しなければならない、変換するのは簡単ですPOSIXからUTCの「人間の解釈」までそれは閏秒の知識を必要としません。なぜなら、毎日の秒数が同じであると仮定しているからです（実際には、これらの秒のうちのいくつかの時間が異なっています）。実際には、POSIX Specの式の逆数を使って、UTCのさまざまな時間成分を取得するだけです（もう一度、Meno Hochschildが参照するPOSIX仕様を参照してください）。

Answer 1

JSR-310-backportは、Java 8に含まれる機能のみをサポートしています。TAI（および真のUTC）はサポートされていないため、バックポートにはありません。唯一の選択肢はTAIInstantクラスを含むthreeten-extra-projectを試すことですが、余分なプロジェクト全体が最新ではないかもしれません（非常に古いコード）。

自分自身のライブラリであるTime4Jに、POSIXに加えTAI、GPS、およびUTCをサポートしています。

[更新日：2014年7月12日：Time4Jは安定版time4j-v1.0として入手可能です。この議論は考慮されています。例えばMoment.toString(TimeScale) を参照してください。]

---

OPの新規投稿の質問への訂正と詳細な注釈：

A）はい、TAIは単調でもうるう秒の間、SI-秒の単位で増加しています。あなたが望むものだけであれば、TAIを選ぶかもしれませんが、落とし穴があります。市民のタイムスタンプを記述したい場合、TAIは間違ったタイムスタンプを返します（Wikipedia diagramの最初と2番目の列を比較するだけです）。その理由は、単に市民生活がTAIではなく、UTCによって支配されているからです。

b）Wikipediaの図が間違っているとの私のコメントについて、私はそれを再び非常によく見て、私の心を変えました。 POSIXとTAIの関係は固定されていません（1972年には10秒しかオフセットされません）。今まで私はTAIについて、POSIXやUTCについてはそれほど考えなかった。しかし、質問とこの啓発の議論のおかげで、あなたは私のupvoteに値する。すべてが難しいです。異なるタイムスケールで表現されたタイムスタンプについて話すときは、ymdhms形式とepochsec形式の違いを作る必要があります。のは、時間1999-01-01T00で詳細にそれを考えてみましょう：00：00Z（UTC-スケール）：

i) TAI = (29 * 365 + 7) days * 86400 + 22 leap seconds + 10s (offset at 1972) = 915148832 
ii) UTC = TAI - 10 = 915148822 (fixed relation between UTC and TAI on epoch-second-level) 
iii) POSIX = UTC - 22 leap seconds = 915148800 

=> (ymdhms-form); 
    i) TAI (915148800 + 32) = 1999-01-01T00:00:32 (based on TAI-"day" = 86400 SI-secs) 
ii) UTC = 1999-01-01T00:00:00 (stripped off former 22 leap secs in conversion to ymdhms) 
iii) POSIX = 1999-01-01T00:00:00 (fixed relation between UTC and POSIX with exception of leapsecs) 

なぜTAIは、うるう秒をカウントしていないことを声明？それはymdhms形式のleapsecsを数えませんが、もちろんepoch-second-level（単調性要件！）で数えます。そしてPOSIX？これは、うるう秒を一切カウントせず、ymdhms形式ではなく、epoch-secsレベルでもあります。最後に、TAIとPOSIXの間には一定の関係はありません。変換には閏秒のテーブルが必要です。

c）POSIX仕様ではうるう秒動作について何を教えていますか？ hereを参照してください。特に、「実際の時刻と現在の値との間の関係は、エポックからの秒数は不定です」と注意してください。だから、これは閏年にも関係します。もし跳躍前にジャンプしたり、1秒間跳躍したり凍ったりするのは、実装までのクロックです。

d）はい、System.currentTimeMillis()はPOSIX Time（秒ではなくミリ秒でも）に相当します。

e）ラベルTAIは1971年以前には定義されておらず、国際原子時計は1958年以前ではないため、threeten-extra-class TAIInstantのプロレプティックスケールは何とかナンセンスです。だから私は1972年以前にTAIを適用しないだろう。ここで私は時間スケールの専門家、スティーブ・アレンと行く。

f）「JVMとマシン間で移植可能」な時間オブジェクトが必要な場合、UTC自体にはどこでも同じ閏秒テーブルの配布/存在が必要です。 TAIを選択した場合でも、アプリケーションがTAIタイムスタンプをUTCまたはPOSIXタイムスタンプに変換できるようにするには、この閏秒テーブルが必要です。ですから、単調に増加するタイムスタンプを持ち、同時にうるう秒を無視することはできません。 TAIはこのジレンマの解決法を提供していません。 2013年12月31日からOPの/要約を疑問視する

回答：

TAIとPOSIXについてのあなたの概要は正しいです。

についてUTCについては、UTCが妥協であることを理解する必要があります。一方の側では太陽に追従するように設計されています。他方の側では、UTCスケールの秒はTAIスケールとまったく同じです（SI-second（原子の定義））。あなたは、地球の回転速度が予期せず減速していると言ったときに正しいので、うるう秒は数回挿入されます。 UT1（平均日照時間）とUTCとの間の差は、常に0.9SSI秒より小さくなければならない。だから、これと同じSI秒の事実がUTCのコアアイデアです。さて、JSR-310のエキゾチックなUTC-SLSスケールの適応は、UTCのこれらのコアアイデアと互換性がありません。閏秒の予測可能性については、パリのBIPMは6ヵ月後に必要な閏秒が必要になるかどうかを半年ごとにアナウンスするので、この予測可能性の枠は6ヵ月前になります。

UTCセクションに関する賢明な修正かもしれません、あなたは書いています。「太陽はいつも正午UTC時に最高です。」同様のステートメントは、java.time.Instantクラスのjavadocで、いわゆるjava時間スケールについても示されています。太陽の位置があなたの地位から独立しているとは言いたくないという事実を除いて、それは正午の正しい経度でさえも正しくありません。どうして？天文学的/科学的観点から見ると、太陽の太陽の平均時間はあなたが見ている真の現地太陽の時間と同じではないことを忘れてはならない（ちょうどキーワード「時間の方程式」を与える）。さらに、UTCは依然として原子時間に基づいており、同期に原子時間を使用するため、UT1とUTCの間にいわゆるデルタT関係があります。このデルタは0.9秒のフレーム内にあり、B掲示板のIERS/BIPMによって定期的に公開されています。あなたは太陽の本当の位置を知りたいときや太陽が最も高いときにこのデルタを知る必要があります。

「時間を表す」セクションは、私の意見では少しシンプルすぎます。さて、TAIとPOSIXは秒をカウントすると言えますが、UTCはむしろ年/月/日/...-形式で表されます。しかし、我々は実際に両方の表現をすべてのスケールに適用することができます。しかし、これらの表現を慎重に区別して、どのように変換するかについて徹底的に考える必要があります。 Wikipediaは、ダイアグラムでTAIのymdhms形式を選択したことにも注意してください。コンピュータはシンプルな整数を保存するのに最適です。 POSIXやTAIはその形式で簡単に格納できます。しかし、前にも述べたように、これらの整数の解釈は必ずしも単純ではありません。 TAIの場合は、読みやすい市のymdhms形式（UTCまたはPOSIXのいずれか）に変換するための第二のテーブルを必要とします。

次のセクション「Translating Times」については、ポイント1〜3に同意します。

あなたの最終的な声明「一方、POSIXからUTCの人間の解釈に変換するのは簡単です」うるう秒を除いて正しいです。さて、来るべき図書館で、さまざまなスケール間で適切な翻訳を可能にします。組み込みの設定可能なうるう秒テーブルがあり、将来、IANA-TZDBデータをそのようなテーブルのソースとして使用する予定です。

ほとんどすべてのビジネス開発者は、あまり正確さの必要性がないという事実に気づく必要があります。ほとんどの人はPOSIXとUTCを単純に等しくし、おそらくLinux OSやGoogle NTPサーバーのスムーズなハードウェアソリューションに満足しているでしょう。真のUTCとTAI（これは閏秒を考慮に入れています）では、より多くの努力が必要です。したがって、ソフトウェアアーキテクチャが科学的精度を必要とするかどうかを判断する必要があります。

JSR-310は正式には非常に広範囲のPOSIXには対応していませんが、そのクラスInstantはUTC-SLSと定義されています（この興味深いのはdebateも参照してください）。

最後に、私はこの議論のために優雅です。私の図書館でTAIに関する私の考えを明確にするのにも役立ちました。ありがとう。

Answer 2

クラスTAIInstantなど、UTCInstantのようなものは、JSR-310プロセス中に削除されました。グループは専門の項目であり、コアJDKに入れる必要はないという結論に達しました。私はまだこれが正しい判断であると信じています。

この結果、JSR-310の時間スケールはほとんどサポートされていません。しかし、JSR-310を時間スケールに接続する方法が正式に定義されているため、正確なソースがあれば正確なクロックを作成することができます。誰もがこのソリューションを好むわけではありませんが、主流の人にとっては実用的です。

要約すると、UTCとTAIの別々のクラスのオリジナルデザインは健全です（過去と未来のイベントを処理するのに必要です）。しかし、それはJDKにはあまりにも専門的でした。

threeten-extraプロジェクトは今でthese classesとJDK 8のJARとして利用可能である。