3

長い UTC 日付を日ごとにグループ化する賢明な方法はありますか?

私はそれらを 86400 で変更しますが、うるう秒は考慮されていません。

私はJavaを使用しているので、日付オブジェクトに解析できますが、日付クラスを使用することによるパフォーマンスのオーバーヘッドが少し心配です。

また、Date オブジェクトの年月と日の部分を比較するよりも効率的な方法はありますか?

4

3 に答える 3

3

私はそれらを 86400 で Mod しますが、それはうるう秒を考慮していません....

私はそれがうまくいくと確信しています。実際には、値にうるう秒を含まない標準の Unix タイム ティッカーをエミュレートするため、 API ドキュメントにDateはうるう秒については何も含めるべきではありません。代わりに、うるう秒の開始時にティッカー値を 1 秒戻すことで、59 秒を 2 秒間持続させることです (前の投稿のリンクで説明されているように)。

Date.getTime()したがって、 IS から得られる値は 86400 秒の日数だけで構成されていると想定できます。特定の日にうるう秒があったかどうかを本当に知る必要がある場合は、インターネットでいくつかのテーブルを利用できます (1972 年以降は 23 ～ 24 回しかなく、それ以前のコンピューターの日付ではほとんど考慮されませんでした)。

ハイ

ウィンストン

于 2011-09-23T19:51:02.990 に答える
3

ソース データには最初からうるう秒が確実に含まれていますか? 一部の API は使用でき、一部の API は使用できません。たとえば、Joda Time (組み込みの日付/時刻 API よりもこれをお勧めします)は、うるう秒を使用しません。Java の日付と時刻の API は「時々」実行します。「分単位の秒」の値として 60 と 61 をサポートしますが、サポートはオペレーティング システムによって異なります (以下を参照)。良いサンプル値がある場合は、まずそれを確認します。明らかに、分割するだけで他の何よりも簡単です。

オブジェクトを (またはJoda で)作成する必要がある場合は、他のことを行う前にベンチマークします。パフォーマンスが実際には完全に適切であることがわかるかもしれません。データにとって問題ないものを最適化するために時間を無駄にしても意味がありません。もちろん、サポートする必要があるデータサイズと、最初に必要な速度を決定する必要があります:)DateDateTime

java.util.Dateうるう秒のサポートでさえ、いくらか不確定です。ドキュメントから：

Date クラスは協定世界時 (UTC) を反映することを目的としていますが、Java 仮想マシンのホスト環境によっては正確に反映されない場合があります。ほぼすべての最新のオペレーティング システムでは、すべての場合で 1 日 = 24 × 60 × 60 = 86400 秒と想定されています。ただし、UTC では、1 ～ 2 年に 1 度、「うるう秒」と呼ばれる 1 秒が余分に発生します。うるう秒は常に 1 日の最後の 1 秒として追加され、常に 12 月 31 日または 6 月 30 日に追加されます。ほとんどのコンピューターの時計は、うるう秒の区別を反映できるほど正確ではありません。

Java とうるう秒の混乱についてはかなり良いブログ記事があります。こちらも読んでください。

于 2009-03-24T13:19:38.540 に答える
0
于 2017-04-28T08:05:40.877 に答える