Работа с java.time в Kotlin: любовь, боль, страдания

[@MEJIOMAH]

Я не понял при чем тут зона времени. Такое поведение происходит из-за того, что сначала сравнение идет по Instant (и тут эти два офсета равны), а затем по LocalDateTime которые лежат в основе (и тут compareTo выдает "неожиданный" результат. Это сделано для консистентности с методом equals которую обязан гарантировать compareTo. Если ваш пример поменять на

val inUtc = OffsetDateTime.of(LocalDateTime.of(2021, 4, 25, 10, 0), ZoneOffset.UTC)
val inUtc1 = OffsetDateTime.of(LocalDateTime.of(2021, 4, 25, 11, 0), ZoneOffset.ofTotalSeconds(60*60))
println(inUtc1>=inUtc && inUtc1 <= inUtc)
println(inUtc == inUtc1)

то оба принта выведут false.

Но то что, equals так работает на OffsetDateTime это, конечно, очень неожиданно.

[@hyragano]

Спасибо за исправление. Согласен с Вами.
Единственный момент: во время вызова compareTo первым идет вызов compareInstant в котором первой строкой сравнивается offset, что является частью таймзоны.

[@hyragano]

Касательно перемешивания мух и котлет (isEqual и compare) согласен с Вами. Суть «неожиданности» тут была не в проблемах OffsetDateTime, а неожиданность от использования  comparable с  LocalDateTime и OffsetDateTime, т.е. этакий ССЗБ получается во время перехода. Ровно такая же картина и с другими типа данных может случится.

[@hyragano]

Спасибо за коментарии

[@Nik_kosmo]

Про Java версию — можно заменить два сравнения одним

 first.from.isEqual(second.to) || first.from.isBefore(second.to) 
превращается в
!first.from.isAfter(second.to)

Тоже самое можно и со вторым вариантом проделать.
Тогда возможно и не придется прибегать к сравнению по compareTo

[@hyragano]

Согласен. Спасибо