私の golang アプリケーションではtime.Now().UTC().Unix()、要求認証に使用されるハッシュ関数のソルトの一部として、Unix の 2 番目の解像度のタイムスタンプ (で生成) を使用しています。

このタイムスタンプをデータストアに保存したいという要望があります。ここでの規則は、golang RFC3339Nano functionによって生成された RFC3339 ナノ秒解像度のタイムスタンプ文字列と、認証用のハッシュです。

質問: ハッシュを後で再認証する必要がある場合に、RFC3339Nano を元の Unix タイムスタンプに正確に戻すことができないというリスクはありますか?

Unix タイムスタンプに適用される閏秒に関するいくつかの問題があることは知っています。RFC3339Nano を介したラウンドトリップによって異なるタイムスタンプが発生し、誤って署名が無効になる可能性はありますか?

RFC3339Nano タイムスタンプと Unix タイムスタンプは、同じ time.Time 構造体から生成されます。

閏秒が発生した日に余分な 61 秒を生成するため、それが機能すると考える傾向があります。これは、前の秒と同じ Unix タイムスタンプにマップされると予想されます。ただし、逆は明らかに失敗します。

次のgoコードを実行しました。

次に、Linuxでの結果は

そしてmacOSでは

同じ時間ですが、フォーマットされた結果は異なります。その理由を知っていますか？

( CodeReviewから移行)

私は実験を行い、Java Time をよりよく理解しようとしています。JSR-310 のタイム ゾーンの処理について、私の側で誤解が生じている可能性があります。

解析するタイムスタンプ文字列がありますDateTimeFormatter

上記の値は、サーバーの現地時間が中央ヨーロッパの午前 10 時 39 分であるときに生成されます。夏時間のため、UTC 時間は午前 8 時 39 分です。独自の計算を行って、自分のゾーンにいる時間を見つけることができます。

次のテストは、コンピューターのタイム ゾーンがタイムスタンプ (+2) に表示されているものと同じ場合に機能します。

Java Time がタイムゾーンを調整する方法をよりよく理解するために、入力文字列をいじってみました。しかし、結果は驚くほど間違っています！

テストが失敗するように、入力文字列のタイムゾーンを繰り返し変更しようとしました。たとえば、文字列を次のように変更する2019-08-28T10:39:57+08:00と、パリの午前 2 時を意味します。しかし、上記のテスト コードは、時刻をチェックするときに引き続きパスします。つまり、結果LocalDateTimeの時刻はまだ午前 10 時です。

質問

ソース文字列のタイムゾーンを常に変更しているにもかかわらず、コードが現地時間として 10 を返すのはなぜですか?

LocalDateTime次に、RFC 3339 文字列 (埋め込まれたオフセットの瞬間を表す) を解析し、可能なゾーン調整に関してオブジェクトに変換する正しい方法は何ですか? マシンが CE[S]T タイム ゾーンで実行されているとします。

環境

タイムスタンプをコンピューターの時刻と比較して、古すぎないかどうかを確認する必要があります。つまり、米国の時間がヨーロッパで評価される場合、それは「古すぎる」可能性はありません。

デバッグ目的で、CLI を介して RFC3339 形式で InfluxDB 測定値を読み取りたいのですが、読み取り/書き込み操作を処理する API が既に存在するため、格納されている実際の形式 (Unix エポック ナノ秒) を台無しにしたくありません。 .

ここで提案されているように「influx -precision rfc3339」を発行すると、タイムスタンプがデータベースに保存される形式、または端末に出力される形式にも影響しますか? 私が欲しいのは後者だけです。