問題タブ [jsr310]

JSR 310 を使用して、ミリ秒単位の日時値をタイムゾーン間で変換しようとしています。従来の API を使用するには、ミリ秒単位の値を処理する必要があります。私の場合、それはローカルと UTC/GMT の間にありますが、ソースと宛先のタイムゾーンが関係していることに関係なく、まったく同じコードであると予想されます。これが私の小さなテストプログラムです。最後のローカル DST 変更の前後で数時間にわたって反復するように構成されています。出力が間違っているので、UTCtoLocalMillis が間違っていると思いますが、テスト方法にも問題がある可能性があります。間違った出力とは、私のタイムゾーンでは、UTC を取得するために時間を減算する必要がありますが、コードは実際には時間を追加するということです。第 2 に、DST の開始点も 1 時間ずれています。

最初にローカル タイムゾーンをフェッチしますが、出力を作成するときに Date().toString() が変換を実行しないように、それを UTC にリセットします。

私が望むのは、新しい JSR 310 API を使用して、ミリ秒単位の時間を取り、ソース ZoneID とターゲット ZoneID を取り、変換されたミリ秒を返すメソッドを作成することです。

というLocalDate変数がありdateます。印刷すると 1988-05-05 と表示されます。これを変換して 05.May 1988 として印刷する必要があります。これを行う方法は?

日付の月、日、年を整数として既に持っている場合、それらを使用してLocalDateオブジェクトを作成する最良の方法は何ですか? この投稿String to LocalDateStringを見つけましたが、日付の表現から始まります。

何らかの理由で、現在 Java 8 を使用することはできません - まだ Java 7 のままです。ただし、公式のバックポート ThreeTenを使用して、今すぐ
新しいものを使用したいと思います。JSR-310 date/time APIs

そのホームページには次のように記載されています。

質問:

1. ThreeTenでのあなたの経験は何ですか? いくつかの欠点はありますか？

2. このプロジェクトは、公式の実装と比較してどの程度互換性がありますか?JSR-310

3. ThreeTen から公式の Java 8実装に移行するには、どのくらいの労力が必要ですか?

4. 今すぐ ThreeTen に移行し、後で JSR-310 に移行する価値はありますか? それとも、ThreeTen をスキップして、Java 8 が使用できるようになるまで待つ必要がありますか?

Jackson Datatype JSR310 ページで説明されているライブラリを使用していますが、まだ動作させるのに苦労しています。

次の Bean を構成しました。

REST API を呼び出すと、日付形式の出力はyyyy-MM-dd'T'HH:ss.SSSSSS、たとえば2015-04-11T00:10:38.905847. これは私の AngularJS コードによって問題なく処理されます。

何かをREST APIに送信したい場合、日付は次のように投稿されますyyyy-MM-dd'T'HH:mm:ss.SSS'Z'。2015-04-09T08:30:00.000Z

ジャクソンは最後に「Z」について不平を言い続けます. LocalDateTimeDeserializerドキュメントでを見ると、DateTimeFormatter.ISO_LOCAL_DATE_TIME沸騰する を使用しISO_LOCAL_DATE'T'ISO_LOCAL_TIMEており、オーバーライド ゾーンがないことが言及されています。

だから私は私が作成DateFormatしているに設定する必要があると考えましたObjectMapper：

しかし、これは何もしません。のような単純なものに変更しましたyyyy-MM-ddが、シリアル化された日付は以前の形式のままで、逆シリアル化も影響を受けません。

これを機能させるために、ここで何が間違っていますか? ISO 8601 形式を知る限り、私の JavaScript コードの日付形式は...

注: これは、ThreeTen バックポートを JSR-310 と比較するの複製ではありません。私の質問はより具体的です。

私の会社では、レガシー コードのリファクタリングに ThreeTen-Backport の使用を DevOps に許可しようとしています (これは、WebLogic 10.3.6.0 のデプロイの制約により、Java 6 からアップグレードできず、どのバージョンの Java も使用できません)。バージョン 1.2.1 以降の JodaTime)。

ThreeTen-Backport の Github ページで、DevOps がこのステートメントに問題を抱えていることがわかります。

バックポートはJSR-310の実装ではありません。多くの不要なフープを飛び越える必要があるためです。代わりに、これはユーザーが Java SE 6 および 7 で JSR-310 API をすばやく使用できるようにするための単純なバックポートです。

「実装ではない」とはどういう意味かと聞かれたら、説明できるようにする必要があります。ただし、実装という言葉には広い意味範囲が含まれている可能性があり、それが何を意味するのか、私自身も正確にはわかりません。

だから私の質問は、このような文脈では、実装とバックポートの意味は何ですか? JSR-310 は実装ではなくバックポートであるため、ThreeTen-Backport がJSR-310 の実装ではないのと同じ意味で、私が使用できるものの反例、つまり他の何かの実装はありますか? Java 6 用の JSR-310の実際の実装は、そのようなものが存在するとしたらどのようなものになり、ThreeTen-Backport とどう違うのでしょうか?

Spring Boot アプリケーションで Java 8 DateTime と Jackson jsr 310 のサポートを使用しています。

SerializationFeature.WRITE_DATES_AS_TIMESTAMPSを無効 にして、Jackson に localDatetime を int 配列ではなく文字列にシリアル化するよう強制しました。

しかし、datetime マイクロ秒または nonaseconds が 0 の終わりであるときに、奇妙なフォーマットの問題が見つかりました。シリアル化された結果はdate.format(DateTimeFormatter.ISO_LOCAL_DATE_TIME)と等しい可能性があると思いますが、そうではなく、フォーマットメソッドがゼロを省略しました。

サンプル テスト コードを完成させます。

テストが失敗し、ログ デバッグが出力されます

zonedDateとlocalDate のマイクロ秒は00で終わりますが、offsetDate はそうではありません。また、date.formatは、マイクロ秒が00で終わらない別の結果も取得します。

format の出力結果、toString、json テキスト

1. toStringの結果はJackson シリアライゼーションで望ましい結果になるはずです。上記のロギングでは、OffsetDateTime json node microseconds text は00で終わる必要があります。
2. format メソッドの結果で末尾の00が省略されるのはなぜですか?

完全なサンプル コードは、私の github.com から見つけることができます。

angular-springmvc-サンプルブート

ISODateTest

そんなこと知ってる：

• Instantは、コンピューティング用の「技術的な」タイムスタンプ表現 (ナノ秒) です。
• LocalDateTimeは、人間のタイムゾーンを含む日付/時計表現です。

結局のところ、IMO は両方とも、ほとんどのアプリケーションのユースケースのタイプとして使用できます。例として：現在、日付に基づいて次の実行を計算する必要があるバッチジョブを実行していますが、これら2つのタイプの間の長所/短所を見つけるのに苦労しています(インスタントとタイムゾーン部分のナノ秒精度の利点は別として)の LocalDateTime)。

Instant または LocalDateTime のみを使用するアプリケーションの例を挙げることができますか?

編集: 精度とタイムゾーンに関する LocalDateTime のドキュメントの読み間違いに注意してください