holgerbrandl
01/19/2023, 8:47 PMLocalDateTime.now() + 10.hours
, and I struggle to see what's wrong with it.mbonnin
01/19/2023, 9:28 PMDesmond van der Meer
01/20/2023, 7:14 AMLocalDateTime
then it's ambiguous what happens if you add 10 hours to it because that's when daylight saving time starts. If you just add 10 hours to the clock it would be 8:00, but if just waited 10 hours it would be 9:00.mbonnin
01/20/2023, 9:52 AMLocalDateTime
isn't timezone aware, is it? So arithmetics could be defined without any time zone, leap second, etc.. considerations2023-26-03 22:00
+ 10.hours
could always equal 2023-27-04 08:00
Desmond van der Meer
01/20/2023, 9:53 AMmbonnin
01/20/2023, 9:53 AMDesmond van der Meer
01/20/2023, 9:53 AMmbonnin
01/20/2023, 9:54 AMInstant
isn't very complicatedDesmond van der Meer
01/20/2023, 9:57 AMmbonnin
01/20/2023, 9:57 AMDesmond van der Meer
01/20/2023, 10:02 AMmbonnin
01/20/2023, 10:02 AMDesmond van der Meer
01/20/2023, 10:08 AMholgerbrandl
01/20/2023, 11:46 AMTodd
03/01/2023, 11:44 PMzonedDateTime.toLocalDateTime().minusHours(closeoutHour).toLocalDate()
But in kotlinx.datetime we can’t do arithmetic on the LocalDateTime. However, in this case doing arithmetic on the Instant could get us wrong answers depending on daylight savings time, since the closeout time does not shift. Is there some gotcha I’m missing about the java api in this use case?fun getBusinessDay(instant: Instant, timeZone: TimeZone, closeoutTime: LocalTime): LocalDate {
val localDateTime = instant.toLocalDateTime(timeZone)
return if (localDateTime.time < closeoutTime) {
localDateTime.date.minus(1, DateTimeUnit.DAY)
} else {
localDateTime.date
}
}
mbonnin
03/02/2023, 12:19 AM2
instead of 0
?Todd
03/02/2023, 1:24 AMDmitry Khalanskiy [JB]
03/02/2023, 8:21 AMTodd
03/02/2023, 8:02 PMDmitry Khalanskiy [JB]
03/06/2023, 2:34 PMzonedDateTime.minusHours(closeoutHour).toLocalDate()
would be incorrect, but it looks almost the same.mbonnin
03/22/2023, 2:06 PMLocalDateTime.plusHours()
). Interesting that Java made the opposite choice.