tl; dr

OffsetDateTime target, eta;    // Modern java.time class.
java.util.Date scheduledDate;  // Terrible legacy class.


if (Objects.isNull(eta)) {   // If no eta, fall back to scheduledDate.
    target = scheduledDate.toInstant().atOffset( ZoneOffset.UTC ); // Never use legacy class `java.util.Date` -- when encountered, immediately convert to modern `java.time.Instant`. 
} else {  // Else not null.
    target = eta;
}
return target;

Лучше полностью избегать java.util.Date. При обнаружении немедленно конвертируйте в современный класс Instant и забудьте об объекте Date.

OffsetDateTime target, eta, scheduled;
scheduled = incomingJavaUtilDate.toInstant().atOffset(ZoneOffset.UTC);

target = Objects.isNull(eta) ? scheduledDate : eta;  // Ternary operator. Short way of saying: If eta is null, go with scheduledDate, otherwise go with eta. 
return target;

Date::toString лжет вам

Во-первых, поймите, что java.util.Date представляет момент в формате UTC, всегда в формате UTC^†. Однако его метод toString имеет благие намерения, ужасно сбивая с толку анти-функцию динамического применения текущего часового пояса JVM по умолчанию. Это создает ложное впечатление, что Date имеет часовой пояс, хотя на самом деле это не ^†.

Избегайте устаревших классов даты и времени

Во-вторых, вы напрасно и трагически смешиваете очень хорошие современные классы java.time (OffsetDateTime) с ужасно ужасными устаревшими классами даты и времени (Date). Не делайте этого. Полностью избегайте устаревших классов. Они устарели с принятием JSR 310 еще в 2014 году.

Используйте java.time

Если передать объект java.util.Date, немедленно преобразовать в java.time. Вызовите новые методы преобразования, добавленные к старым классам. Класс Instant напрямую заменяет Date, как момент в UTC, но с более точным разрешением наносекунд по сравнению с миллисекундами.

Instant instant = myJavaUtilDate.toInstant();  // Convert from legacy class to modern class.

Как правило, вы должны отслеживать моменты в формате UTC. Вы можете сделать это как Instant или как OffsetDateTime с его смещением, установленным на константу ZoneOffset.UTC.

OffsetDateTime odt = instant.atOffset(ZoneOffset.UTC);  // Same moment, no change in meaning whatsoever. 

В частности, для UTC в нашем коде здесь нет разницы между instant и odt. Оба они представляют момент по всемирному координированному времени. Разница в том, что OffsetDateTime (a) может нести альтернативное значение смещения от UTC (часы-минуты-секунды), а (b) является более гибким, например, генерирует текст в форматах, отличных от стандартного ISO 8601.

Поймите, что offset-from-UTC - это просто количество часов, минут и секунд. Больше ничего. часовой пояс, напротив, больше много. Часовой пояс - это история прошлых, настоящих и будущих изменений смещения, используемого людьми определенного региона. Например, люди в регионе, использующие часовой пояс America/Los_Angeles, изменяют свое смещение-от-UTC дважды в год в глупой практике, известной как Летнее время (DST), переходя с -08: 00 на -07: 00 и обратно.

Так что, как правило, часовой пояс предпочтительнее простого смещения. Например, чтобы увидеть ваш Date, мы превратили его в Instant через время настенных часов, используемое большинством людей на западном побережье США, примените часовой пояс America/Los_Angeles (ZoneId) к Instant, чтобы получить ZonedDateTime.

ZoneId z = ZoneId.of("America/Los_Angeles");
ZonedDateTime zdt = instant.atZone(z);

Вы можете вернуться в UTC, распаковав Instant.

Instant instant = zdt.toInstant();

А оттуда вернитесь к java.util.Date (если нужно, иначе избегайте).

java.util.Date d = java.util.Date.from(instant);

^† На самом деле, у класса делаетjava.time.Date есть часовой пояс, скрытый глубоко внутри. При отсутствии каких-либо методов доступа (get / set) он недоступен. Его поведение не имеет отношения к нашему обсуждению здесь. Сбивает с толку? да. Еще одна из многих причин избегать ужасных устаревших классов даты и времени.