Комментарии 6
Я не понял при чем тут зона времени. Такое поведение происходит из-за того, что сначала сравнение идет по 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 это, конечно, очень неожиданно.
Спасибо за исправление. Согласен с Вами.
Единственный момент: во время вызова compareTo первым идет вызов compareInstant в котором первой строкой сравнивается offset, что является частью таймзоны.
Единственный момент: во время вызова compareTo первым идет вызов compareInstant в котором первой строкой сравнивается offset, что является частью таймзоны.
Касательно перемешивания мух и котлет (isEqual и compare) согласен с Вами. Суть «неожиданности» тут была не в проблемах OffsetDateTime, а неожиданность от использования comparable с LocalDateTime и OffsetDateTime, т.е. этакий ССЗБ получается во время перехода. Ровно такая же картина и с другими типа данных может случится.
Спасибо за коментарии
Про Java версию — можно заменить два сравнения одним
Тоже самое можно и со вторым вариантом проделать.
Тогда возможно и не придется прибегать к сравнению по compareTo
first.from.isEqual(second.to) || first.from.isBefore(second.to)
превращается в
!first.from.isAfter(second.to)
Тоже самое можно и со вторым вариантом проделать.
Тогда возможно и не придется прибегать к сравнению по compareTo
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Работа с java.time в Kotlin: любовь, боль, страдания