Trabalhando com java.time em Kotlin: amor, dor, sofrimento

Um micropost sobre como você pode se enganar ao usar o recurso Kotlin: a capacidade de trabalhar com operadores de comparação como Comparable.

Quem usa Kotlin não pode deixar de apreciar a sobrecarga de operadores (bem, mais precisamente, como isso é feito), embora eu diga que morei em Java e está tudo bem sem ele, mas não se trata desse recurso de linguagem, mas de cerca aquele baseado nele: Operações de comparação. É quando os sinais de comparação podem ser aplicados às classes que implementam Comparable, que é açucarado, mas muito bom.

E então, vamos praticar sintéticos: temos algum tipo de período de tempo, ou seja, data e hora de início e término e precisamos verificar o fato da interseção dos intervalos de tempo.

Em Java (escrevo o mais breve possível e sem normas aceitas, apenas transmito a ideia):

class TimeIterval {
  LocalDateTime from;
  LocalDateTime to;
}
class TimeIntervalUtil {
  public boolean areOverlapped(TimeInterval first, TimeInterval second) {
            return (first.from.isEqual(second.to) || first.from.isBefore(second.to)) &&
                (first.to.isEqual(second.from) || first.to.isAfter(second.from));
  }
}
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
    

Essa. nada complicado, mas apenas no caso de explicarei o código (tenho que explicar este código a mim mesmo quando o encontrar): a interseção de dois intervalos só é possível se a data de início de um veio mais cedo ou ao mesmo tempo em relação à data de término do segundo e, ao mesmo tempo, a data de término do primeiro intervalo vem depois ou no início do segundo.

Agora a mesma coisa, mas em Kotlin com seu açúcar, mas sem os rangers:

data class TimeInterval(val from: LocalDateTime, val to: LocalDateTime)
fun areOverlapped(first: TimeInterval, second: TimeInterval): Boolean = 
  first.from <= second.to && first.to >= second.from
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
    

Bem, acho que sem comentários onde você pode ver melhor, o que é mais agradável de usar e entender mais rápido. Satisfeitos, vamos para Kotlin e começamos a trabalhar por analogia com OffsetDateTime.

, OffsetDateTime. Comparable, java.time. LocalDateTime. Java , .

compareTo, Kotlin , LocalDateTime ( , , ), .

OffsetDateTime , , compareTo , .. 2021-04-25 10:00+0 2021-04-25 11:00+1 . :

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.isEqual(inUtc1))
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
    

Claro, é correto usar não isEqual aqui, mas - == e geralmente separar isEqual + isBefore + isAfter e Comparable + equal, mas infelizmente às vezes não percebo a diferença, especialmente quando tenho uma abordagem conveniente com operadores de comparação .

É assim que você pode facilmente e naturalmente criar um bug não óbvio no caso do uso impensado de operadores de comparação no Kottlein com a api java.time.