Previous/next date and/or time with the given form

[dkhalanskyjb]

"I have a date or a time, and I want to round/adjust it."

Examples:

• Find the last time it was Monday (or Sunday) not later than the given date: Allow getting the week number of a LocalDate and a LocalDateTime #129 (comment)
• Given the local time, find the 1-hour slot it matches (13:45:12.513 -> 13:00:00.000): set hours of LocalDateTime #223 (comment)
• Discard the sub-minute components when formatting a Duration: Feature Request: truncateTo for LocalTime #225 (comment) (can also be solved by tweaking the formatter).
• Find the next time a given day of the week happens: Add an equivalent of TemporalAdjusters #235 (comment)
• Internally, we need functions like "find the last Sunday in the given month" to calculate the moments when timezone transitions happen.

[volkert-fastned]

One practical use case for such functionality: the OCPP specification. It mandates that ISO date/time strings don't have more than 3 decimal points:

number of decimal places SHALL NOT exceed the maximum of 3.

In other words: no more than millisecond precision.

While working with kotlinx-datetime, we actually ran into compatibility problems with vendors that will flat out reject the nanosecond-precise ISO date/time strings that kotlinx.datetime.Instant gets serialized to by kotlinx.serialization.

We could use JSR-310 (java.time) instead, so we could solve it with truncateTo, or we can write a helper function as suggested on StackOverflow, but I was kind of hoping that there would be an equally convenient built-in multiplatform solution for this.

[volkert-fastned]

Update:

I found a single-line workaround for forcibly reducing the precision to millisecond-level in serialized ISO date/time strings, at least for timestamps originating from the system clock:

import kotlinx.datetime.Clock
import kotlinx.datetime.Instant

// Will have 6 digits behind the decimal point on Kotlin/JVM, but 3 digits on Kotlin/JS and Kotlin/Native
println(Clock.System.now())

// Will have 3 digits behind the decimal point on Kotlin/JVM, Kotlin/JS and Kotlin/Native
println(Instant.fromEpochMilliseconds(Clock.System.now().toEpochMilliseconds()))

So Kotlin/JVM appears to appears to be the only Kotlin platform that creates Instants from the system clock at nanosecond precision, although I haven't tried it with Kotlin for Android yet.

[dkhalanskyjb]

@volkert-fastned, since your problem is with system interoperability, the upcoming API for parsing and formatting may solve it: #343

[alghe-global]

I've the use case where I want to check whether a day (LocalDate) is in current week or current month. I don't think there's support for this yet, and I think this issue would help - correct me if I'm wrong. Is there any chance this will be implemented soon?

LE: here's the equivalent code using Java API (in Kotlin) of what I'm trying to do

fun isCurrentDay(timestamp: Long): Boolean {
    val instant = Instant.ofEpochMilli(timestamp)
    val currentLocalDate = LocalDate.now(ZoneId.systemDefault())
    val timestampLocalDate = instant.atZone(ZoneId.systemDefault()).toLocalDate()
    return currentLocalDate == timestampLocalDate
}

fun isCurrentWeek(timestamp: Long): Boolean {
    val instant = Instant.ofEpochMilli(timestamp)
    val currentLocalDate = LocalDate.now(ZoneId.systemDefault())
    val timestampLocalDate = instant.atZone(ZoneId.systemDefault()).toLocalDate()

    val currentWeekStart = currentLocalDate.with(TemporalAdjusters.previousOrSame(DayOfWeek.MONDAY))
    val currentWeekEnd = currentWeekStart.plusDays(6)

    return timestampLocalDate in currentWeekStart..currentWeekEnd
}

fun isCurrentMonth(timestamp: Long): Boolean {
    val instant = Instant.ofEpochMilli(timestamp)
    val currentLocalDate = LocalDate.now(ZoneId.systemDefault())
    val timestampLocalDate = instant.atZone(ZoneId.systemDefault()).toLocalDate()

    val currentMonthStart = currentLocalDate.with(TemporalAdjusters.firstDayOfMonth())
    val currentMonthEnd = currentMonthStart.plusDays(
        (currentLocalDate.lengthOfMonth() - 1).toLong()
    )

    return timestampLocalDate in currentMonthStart..currentMonthEnd
}

[dkhalanskyjb]

@alghe-global, here are some kotlinx-datetime implementations:

import kotlinx.datetime.*

fun LocalDate.isSameDay(timestamp: Long): Boolean =
    this == timestampToDateInSystemTimeZone(timestamp)

fun LocalDate.isSameWeek(timestamp: Long): Boolean =
    previousOrSame(DayOfWeek.MONDAY) ==
        timestampToDateInSystemTimeZone(timestamp).previousOrSame(DayOfWeek.MONDAY)

fun LocalDate.isSameMonth(timestamp: Long): Boolean {
    val timestampLocalDate = timestampToDateInSystemTimeZone(timestamp)
    return year == timestampLocalDate.year && month == timestampLocalDate.month
}
/*
// After https://github.com/Kotlin/kotlinx-datetime/pull/457:
fun LocalDate.isSameMonth(timestamp: Long): Boolean =
    yearMonth == timestampToDateInSystemTimeZone(timestamp).yearMonth
*/

private fun timestampToDateInSystemTimeZone(timestampMillis: Long) =
    Instant.fromEpochMilliseconds(timestampMillis).toLocalDateTime(TimeZone.currentSystemDefault()).date
    
// https://github.com/Kotlin/kotlinx-datetime/issues/129#issuecomment-1152301045
private fun LocalDate.previousOrSame(requiredDayOfWeek: DayOfWeek): LocalDate =
    minus((dayOfWeek.isoDayNumber - requiredDayOfWeek.isoDayNumber).mod(7), DateTimeUnit.DAY)

The "current week" use case would indeed benefit from temporal-adjuster-style functionality, but as a workaround, you could copy this implementation of previousOrSame to your code.

[chrisjenx]

Another missing use case of ZonedDateTime is something like this which we do allot of billing to make sure we doing close to midnight as possible:

request.billingStartDate
                .toJodaDateTime(request.billingTimeZone)
                .withTimeAtStartOfDay(),

To get this, we have to convert to JodaDateTime to be able to work out the midnight in that time zone, LocalDateTime or Instant doens't know this without being timezone aware.

[dkhalanskyjb]

@chrisjenx, did you try https://kotlinlang.org/api/kotlinx-datetime/kotlinx-datetime/kotlinx.datetime/at-start-of-day-in.html ? Also, there is no need to repeat your message in several threads, we are reading everything that's submitted to the issue tracker.

[chrisjenx]

That only works on getting an Instant, in this case we already have a Instant from our API call. so you have to do this insanity:

Instant -> LocalDateTime -> LocalDate -> atTimeWithStartOfDay -> Instant

Thankfully we send timezones separately in our api requests otherwise this would be impossible, then we also want todo things like this ALL the time esp in testing:

System.now().withTime(7,0,0) // 7am

Which obviously is messy as instant isn't zoned. I know you keep shooting it down, but there needs to be a comparable DateTime/ZonedDateTime to Joda/Java8 API's.

Also I cross posted as wasn't sure which ticket it should go in

[dkhalanskyjb]

so you have to do this insanity:

instant.toLocalDateTime(zone).date.atStartOfDayIn(zone)? I don't see what's insane about this. This line of code captures my intuition behind this operation perfectly:

• I want the moment of the start (atStartOfDayIn)
• of the day (.date)
• that also contained the given moment (instant)
• in the given time zone (.toLocalDateTime(zone))

If this is too verbose and your business domain has a shorter name for this operation, you can add an extension function with that name in your code.

Thankfully we send timezones separately in our api requests otherwise this would be impossible

Sure, it's impossible to correctly perform this operation without knowing both the instant and the time zone, no matter what API you are using. What is your point here?

then we also want todo things like this ALL the time esp in testing:
System.now().withTime(7,0,0) // 7am

Could you describe this use case in more detail? If there is no 07:00 at that time zone at that moment, what should be returned? Say, if 06:30 jumps directly to 07:30, should the result be 08:30, 07:30, or something else, and why?

I know you keep shooting it down, but there needs to be a comparable DateTime/ZonedDateTime to Joda/Java8 API's.

I think "shooting it down" is an emotionally charged and incorrect description, as I personally am fully in favor of introducing ZonedDateTime as LocalDateTime + TimeZone. Unless, of course, you are talking about a complete equivalent to Java's ZonedDateTime (Instant + TimeZone); in that case, true, I'm shooting it down, as I can't remember seeing anyone provide a single use case for it that wasn't better covered by LocalDateTime + TimeZone. Do you have such a use case?