Может показаться, что эта необходимость не была предусмотрена в проекте. Для этого, казалось бы, простого требования не существует действительно хорошего и естественного варианта.
Мне нравится выбирать из чего-то. deHaar уже предоставил два варианта, которые настолько хороши, насколько мы можем получить. Итак, в качестве дополнения вот третий: преобразование в секундах и наносекундах с начала эпохи и общего смещения секунд .
org.threeten.bp.OffsetDateTime fromThirdParty
= org.threeten.bp.OffsetDateTime.of(2020, 1, 25, 23, 34, 56, 123456789,
org.threeten.bp.ZoneOffset.ofHours(1));
java.time.Instant jtInstant = java.time.Instant
.ofEpochSecond(fromThirdParty.toEpochSecond(), fromThirdParty.getNano());
java.time.ZoneOffset jtOffset = java.time.ZoneOffset.ofTotalSeconds(
fromThirdParty.getOffset().getTotalSeconds());
java.time.OffsetDateTime converted
= java.time.OffsetDateTime.ofInstant(jtInstant, jtOffset);
System.out.println("From " + fromThirdParty);
System.out.println("To " + converted);
Выходные данные из этого фрагмента:
From 2020-01-25T23:34:56.123456789+01:00
To 2020-01-25T23:34:56.123456789+01:00
Возможные преимущества включают в себя: Мы переносим 3 числовых поля (против 7 в первом преобразовании де Хаара), тем самым снижая риск переноса неправильного значения по ошибке. И мы все еще избегаем форматирования в строку и разбора обратно (что для меня кажется пустой тратой, но приятно и коротко).
И, пожалуйста, оберните его в метод с хорошим именем, как это сделал деХаар.