// 変換するJSON
String json = """
    "sqlTimestamp"              : "2023-11-13 12:00:00.789",
    "sqlTimestampWithTimezone"  : "2023-11-13 12:00:00.789+09:00",
    "localDateTime"             : "2023-11-13T12:00:00.123456",
    "offsetDateTime"            : "2023-11-13T12:00:00.123456+09:00"
    }""";
// Json -> オブジェクト ～1回目～
ObjectMapper mapper = new ObjectMapper();
Sample sample = mapper
    .registerModule(new JavaTimeModule()).readValue(json, Sample.class);
System.out.println(sample.sqlTimestamp); // 2023-11-13 12:00:00.789
System.out.println(sample.sqlTimestampWithTimezone); // 2023-11-13 12:00:00.789
System.out.println(sample.localDateTime); // 2023-11-13T12:00:00.123456
System.out.println(sample.offsetDateTime); // 2023-11-13T03:00:00.123456Z
// Json -> オブジェクト ～2回目～
ObjectMapper mapperWithTimezone = new ObjectMapper().setTimeZone(TimeZone.getTimeZone("Asia/Tokyo"));
Sample sample2 = mapperWithTimezone
    .registerModule(new JavaTimeModule()).readValue(json, Sample.class);
System.out.println(sample2.sqlTimestamp); // 2023-11-13 12:00:00.789
System.out.println(sample2.sqlTimestampWithTimezone); // 2023-11-13 12:00:00.789
System.out.println(sample2.localDateTime); // 2023-11-13T12:00:00.123456
System.out.println(sample2.offsetDateTime); // 2023-11-13T12:00:00.123456+09:00

import java.time.LocalDateTime;
import java.time.OffsetDateTime;
import com.fasterxml.jackson.annotation.JsonFormat;
public class Sample {
  @JsonFormat(pattern = "yyyy-MM-dd hh:mm:ss.SSS", timezone = "Asia/Tokyo")
  public java.sql.Timestamp sqlTimestamp;
  @JsonFormat(pattern = "yyyy-MM-dd hh:mm:ss.SSSXXX", timezone = "Asia/Tokyo")
  public java.sql.Timestamp sqlTimestampWithTimezone;
  @JsonFormat(pattern = "yyyy-MM-dd'T'hh:mm:ss.SSSSSS", timezone = "Asia/Tokyo")
  public LocalDateTime localDateTime;
  @JsonFormat(pattern = "yyyy-MM-dd'T'hh:mm:ss.SSSSSSxxx", timezone = "Asia/Tokyo")
  public OffsetDateTime  offsetDateTime;
注意すべきこと
// Json -> オブジェクト ～1回目～
ObjectMapper mapper = new ObjectMapper();
(略)
System.out.println(sample.offsetDateTime); // 2023-11-13T03:00:00.123456Z
// Json -> オブジェクト ～2回目～
ObjectMapper mapperWithTimezone = new ObjectMapper().setTimeZone(TimeZone.getTimeZone("Asia/Tokyo"));
(略)
System.out.println(sample2.offsetDateTime); // 2023-11-13T12:00:00.123456+09:00
(サンプルコードから一部抜粋)
サンプルコードの「// Json -> オブジェクト ～1回目～」では、 ObjectMapper を何も指定せずインスタンス生成していますが、そのインスタンスを使用して変換した変数「offsetDateTime」は9時間巻き戻った値が格納されています。
一方、「// Json -> オブジェクト ～2回目～」では、タイムゾーンを指定して ObjectMapper をインスタンス生成しており、そちらのインスタンスを使用して変換した変数「offsetDateTime」は JSON に格納された時刻のまま格納されています。
Jackson は TimeZone をデフォルトのUTCで扱うようになっており、 UTC でないタイムゾーンを使用したい場合は ObjectMapper の生成時に指定してあげないといけないので注意が必要です。
日付時刻クラス

Javaには日付・時刻を取り扱うクラスがいくつか存在します。
初期から日付・時刻に関するクラスは存在していますが、JDK8以降に一新されました。JDK7以前のクラスは使いにくいものや非推奨となったものもあるため、JDK8で追加された Date and Time API のなかから説明していきます。
Date and Time API の中で、日付と時刻 (年, 月, 日, 時, 分, 秒, ナノ秒) を表すクラスは、「java.time.LocalDateTime」,「java.time.OffsetDateTime」,「java.time.ZonedDateTime」の3つとなります。その3つのクラスで使用されるタイムゾーン情報を表すクラスは、「java.time.ZoneId」,「java.time.ZoneOffset」の2つです。
【日付時刻クラス】
java.time.LocalDateTime
タイムゾーンのない日時
例：2024-01-01T00:00:00.0
java.time.OffsetDateTime
オフセット付きの日時
例：2024-01-01T00:00:00.0+09:00
java.time.ZonedDateTime
タイムゾーン付きの日時
例：2024-01-01T00:00:00.0+09:00[Asia/Tokyo]
【日付時刻クラスで使用するクラス】
java.time.ZoneId
地域と時差のルールを定義している
夏時間・冬時間の考慮あり
例： "Asia/Tokyo"
java.time.ZoneOffset
UTCからの時差
夏時間・冬時間の考慮なし
例： +09:00
LocalDateTime
LocalDateTime は、タイムゾーン情報を持たない日付・時刻を扱うクラスです。タイムゾーン情報を持たないので、世界共通時間軸上におけるどこの国・地域の時刻を指しているかは特定することができません。
ユーザー等の外部入力されたデータにはタイムゾーンがない場合は多々あり、そこで  LocalDateTime として受け取る/渡すことがあります。ただ、「タイムゾーンの必要性」でも述べた通り、タイムゾーンの情報のない時刻のまま運用するとバグを引き起こす可能性があります。 LocalDateTime として受け取った場合、早い段階で LocalDateTime タイムゾーンを特定してその時刻にタイムゾーン情報を付与しましょう。
OffsetDateTime
OffsetDateTime は、オフセット ( ZoneOffset ) と呼ばれるUTCからの時差のみをタイムゾーン情報として持つ日付・時刻を扱うクラスです。
OffsetDateTime は ZonedDateTime とは違い、サマータイム (ウィンタータイム) を考慮しません。存在しない時刻や重複時刻を気にする必要がなく、UNIX時間に変換することが可能となります。
UNIX時間とは...

コンピューターにおける時刻表現方法の1つです。エポックタイムとも呼ばれます。
UTCで「1970年1月1日午前0時0分0秒」を基準にして、そこからの経過秒数で日時を表現します。
1970年1月1日午前0時0分1秒の場合、UNIX時間は「1」となります。
UNIX時間はうるう秒を考慮しません。
サマータイム (ウィンタータイム) を考慮しなくてよいという理由から、DB等への時刻の保存は OffsetDateTime の使用が推奨されます。
サマータイムの開始前と開始後でタイムゾーンがずれてないことが分かります。
// ※2023/11/13に実施しました
// サマータイム開始前
OffsetDateTime newYork = OffsetDateTime.now(ZoneId.of("America/New_York"));
// サマータイムが開始済みの4月まで時間を足す
OffsetDateTime newYorkPlus5M = newYork.plusMonths(5);
System.out.println(newYork); // 2023-11-13T21:54:38.209701-05:00
System.out.println(newYorkPlus5M); // 2024-04-13T21:54:38.209701-05:00
ZonedDateTime
ZonedDateTime は、地域と時差のルール定義 ( ZoneId ) をタイムゾーン情報として持つ日付・時刻を扱うクラスです。
ZonedDateTime はサマータイム (ウィンタータイム) を考慮して計算を行います。
サマータイムの開始前と開始後でタイムゾーンが1時間ずれている (「-05:00」が「-04:00」に変化) ことが分かります。
// ※2023/11/13に実施しました
// サマータイム開始前
ZonedDateTime newYork = ZonedDateTime.now(ZoneId.of("America/New_York"));
// サマータイムが開始済みの4月まで時間を足す
ZonedDateTime newYorkPlus5M = newYork.plusMonths(5);
System.out.println(newYork); // 2023-11-13T21:54:38.209701-05:00[America/New_York]
System.out.println(newYorkPlus5M); // 2024-04-13T21:54:38.209701-04:00[America/New_York]




    

ZonedDateTime の注意
ZonedDateTime はサマータイム (ウィンタータイム) を考慮されますので、サマータイム開始前の ZonedDateTime インスタンスにサマータイム開始後の状態へ時間を経過させると UNIX時間にずれが生じます。それらを使用する際はご注意ください。
実際に試したのが下記です。
3月1日の OffsetDateTime インスタンスに1か月足すと、UNIX時間では2678400秒 (31(日)×24(時間)×60(分)×60(秒)) が足された事になります。ですが、3月1日の ZonedDateTime インスタンスに1か月足すと、UNIX時間では2674800秒 (31(日)×24(時間)×60(分)×60(秒) - 1(時間)×60(分)×60(秒)) となり、その差は3600秒です。 OffsetDateTime と比べて1時間短い値となってしまいます。
// OffsetDateTime
// サマータイム開始前の3月1日の UNIX時間(秒)を出す(ニューヨークとUTCの時差は-5時間)
OffsetDateTime odt = OffsetDateTime.of(2023,3,1,0,0,0,0,ZoneOffset.ofHours(-5));
long odtEpoch = odt.toEpochSecond();
// 1か月足してサマータイム開始済みにし、UNIX時間(秒)を出す
OffsetDateTime odtPlus = odt.plusMonths(1);
long odtPlusEpoch = odtPlus.toEpochSecond();
// UNIX時間(秒)を比較する
System.out.println("OffsetDateTime:" + (odtPlusEpoch - odtEpoch)); // 2678400
// ZonedDateTime
// サマータイム開始前の3月1日の UNIX時間(秒)を出す
ZonedDateTime zdt = ZonedDateTime.of(2023,3,1,0,0,0,0,ZoneId.of("America/New_York"));
long zdtEpoch = zdt.toEpochSecond();
// 1か月足してサマータイム開始済みにし、UNIX時間(秒)を出す
ZonedDateTime zdtPlus = zdt.plusMonths(1);
long zdtPlusEpoch = zdtPlus.toEpochSecond();
// UNIX時間(秒)を比較する
System.out.println("ZonedDateTime:" + (zdtPlusEpoch - zdtEpoch)); //　2674800
日付・時刻クラス(JDK8以降)で有用なメソッド
・ 現在時刻の取得 (nowメソッド)
日付時刻 (LocalDateTime, OffsetDateTime, ZonedDateTime) 共通のメソッド
(代表でLocalDateTimeを記す)
// デフォルトのタイムゾーンを使用して現在時刻を返却する。
LocalDateTime now = LocalDateTime.now();
// 引数のタイムゾーンを使用して現在時刻を返却する。
LocalDateTime now = LocalDateTime.now(ZoneId.of("Asia/Tokyo"));
・ インスタンス生成 (ofメソッド)
// LocalDateTime (年月日時分秒を指定)
LocalDateTime now = LocalDateTime.of(2023, 11, 13, 0, 0, 0);
// OffsetDateTime (年月日時分秒ナノ秒、オフセットを指定)
OffsetDateTime now = OffsetDateTime.of(2023, 11, 13, 0, 0, 0, 0, ZoneOffset.ofHours(9));
// ZonedDateTime (年月日時分秒ナノ秒、タイムゾーンを指定)
ZonedDateTime now = ZonedDateTime.of(2023, 11, 13, 0, 0, 0, 0, ZoneId.of("Asia/Tokyo"));
・ LocalDateTime型から、ZonedDateTime型 や OffsetDateTime型 に変換する
LocalDateTime ldt = LocalDateTime.now();
//LocalDateTime -> ZoneDateTime
ZonedDateTime zdt = ldt.atZone(ZoneId.systemDefault());
//LocalDateTime -> OffsetDateTime
OffsetDateTime odt = ldt.atOffset(ZoneOffset.ofHours(9));
うるう秒について

現在のJavaの標準APIではうるう秒を扱うことができず、ZonedDateTime 型や LocalDateTime 型で60秒を指定できません。
よって、クライアントやフロントエンドから60秒が送られてきた場合、Javaの標準APIではエラーとなってしまいます。
ですが、2012年にうるう秒挿入によるシステム障害が起きてから多くのOSやタイムサーバーではうるう秒の対策がなされており、現在60秒を挿入しない場合が多いようです。
// 60秒を指定する
LocalDateTime ldt = LocalDateTime.of(2023,11,13,23,59,60);
// 下記のエラーが出る
Exception in thread "main" java.time.DateTimeException: Invalid value for SecondOfMinute (valid values 0 - 59): 60
(略)
外部ライブラリ ( ThreeTen-Extra ) を使用すればうるう秒を扱うことが可能です。
Javaで日付・時刻を扱う時に注意すべき点のまとめ

ユーザーの入出力の時刻 ( LocalDateTime ) を受け取った際は、タイムゾーン付き時刻 ( ZonedDateTime ) へ変換すること
ある1つのタイムゾーンのなかで生活する方であればタイムゾーンや時差を意識することはないため、Webサービスでユーザーに時刻を入力/表示させるときには、タイムゾーンや時差も入力/表示させることは基本ありません。
故に、ユーザーからはタイムゾーンや時差の情報がない日付時刻が送られてくることがあります。それらを受け取った際に、こちらはユーザーのタイムゾーンの時刻として解釈しなければなりません。ユーザーのタイムゾーンを特定したら、すぐタイムゾーン情報を格納して処理するようにしましょう。
時刻の保存やシステム間のやり取りは、OffsetDateTime の型で行うこと
ZonedDateTime はサマータイム (ウィンタータイム) が考慮されて時間計算が行われており、サマータイム (ウィンタータイム) の開始前後と終了前後では時間のずれが生じます。その結果、トラブルが発生してしまうことがあります。
例えば、あるシステムにおいて3月頭から1か月のライセンス(3月1日0時0分0秒から3月31日23時59分59秒まで)を付与したとします。日本は2023年現在サマータイムが導入されていないので、使用可能時間は2678399秒 (31(日)×24(時間)×60(分)×60(秒)-1(秒))となりますが、ニューヨークはサマータイムが3月第2日曜日に導入されて1時間早まっているため、2674799秒 (31(日)×24(時間)×60(分)×60(秒) - 1(時間)×60(分)×60(秒)-1(秒))となり、単純なライセンス使用可能時間が短くなってしまいます。
このように意図しない挙動やトラブルの回避のため、時刻の保存は何か特別な理由がない限り UTC からのオフセット情報が付いた日付・時刻で扱う方が良いでしょう。
O/Rマッパーでの日付・時刻の扱い方

オブジェクトとデータベース間のデータ形式を変換するために使われるのが、O/Rマッパーです。
O/Rマッパーにもタイムゾーンの概念はあるので、タイムゾーンを意識しなければなりません。
ここでは、HibernateとMyBatisを紹介します。
Hibernate

Hibernateは、Javaでデータベースを扱うためのO/Rマッパーです。
yamlで下記のように書くことでタイムゾーンを指定することができます。
spring:
  jpa:
    properties:
      hibernate:
        jdbc:
          time_zone: UTC
(引用サイト : https://www.baeldung.com/mysql-jdbc-timezone-spring-boot ⧉ )
MyBatis

MyBatisは、Javaでデータベースを扱うためのO/Rマッパーで、SQL文とオブジェクトをマッピングします。
MyBatis自体にタイムゾーンの設定があるわけではなく、SQL文とオブジェクト間で変換される時に必ず通る Handler 部で時刻のタイムゾーンの設定を変えて値をセットするのが良いかと思われます。
Javaのオブジェクトへ変換する際に、Date and Time API で提供されている型を使用したい場合も、Handler で実現できます。Type Handler というモジュールを使用します。
例えば、JDBCの TIMESTAMP 型を Java の java.time.OffsetDateTime 型に変換したいとき、OffsetDateTimeTypeHandler を使用するとマッピングしてくれます。(※ Ver3.4.5以前は、別ライブラリ( mybatis-typehandlers-jsr310 )が必要です)
リレーショナルデータベースでの日付・時刻の扱い方

次にリレーショナルデータベース (以下「データベース」とする) の日付・時刻のデータ型やタイムゾーンの変更の仕方です。
時刻の取り扱いはデータベース毎に異なりますので、解釈を間違わないように使用する前に公式HP等を確認しましょう。
また、Javaの章で「時刻の保存は、OffsetDateTime の型で行うこと」と述べたように、オフセットが付いた日付・時刻でデータベースに保存しましょう。オフセットをつけるためには、データ型はタイムゾーンと一緒に保存できるものでなければいけません。使用するデータ型がタイムゾーンをセットできるか確認してから使いましょう。
そして、データベースは独自でデフォルトのタイムゾーンを持っていることがほとんどです。初期設定がどこのタイムゾーンなのか確認し、必要があれば設定を変えましょう。
こちらでは、PostgreSQL, MySQLをご紹介します。
PostgreSQL

PostgreSQLで日付・時刻を扱えるデータ型は下記です。
型名
格納サイズ
説明
最遠の過去
最遠の未来
精度
timestamp [ (p) ] [ without time zone ]
8 バイト
日付と時刻両方（時間帯なし）
4713 BC
294276 AD
1マイクロ秒
timestamp [ (p) ] with time zone
8バイト
日付と時刻両方、時間帯付き
4713 BC
294276 AD
1マイクロ秒