What is the purpose of specifying TimeZone?

[ArcherEmiya05]

I am 1 day or hours behind from the device time.

Original code

        val dateFormatter = LocalDateTime.Format { // yyyy-MM-dd
            year()
            char('-')
            monthNumber()
            char('-')
            dayOfMonth()
        }

        val now = Clock.System.now()

        val currentDate = now.toLocalDateTime(TimeZone.UTC)

        val currentDateInMilli = currentDate.toInstant(TimeZone.UTC).toEpochMilliseconds()
        val oldestDateInMilli = now.minus(currentDate.year - 2009L, DateTimeUnit.YEAR, TimeZone.UTC).toEpochMilliseconds()
        val previousMonthInMilli = now.minus(1, DateTimeUnit.MONTH, TimeZone.UTC).toEpochMilliseconds()

       // Some processing of currentDateInMilli

       txtView.text = Instant.fromEpochMilliseconds(it).toLocalDateTime(TimeZone.currentSystemDefault()).format(dateFormatter)

Attempt with

        val dateFormatter = LocalDateTime.Format { // yyyy-MM-dd
            year()
            char('-')
            monthNumber()
            char('-')
            dayOfMonth()
        }

        val now = Clock.System.now()

        val currentDate = now.toLocalDateTime(TimeZone.currentSystemDefault())

        val currentDateInMilli = currentDate.toInstant(TimeZone.currentSystemDefault()).toEpochMilliseconds()
        val oldestDateInMilli = now.minus(currentDate.year - 2009L, DateTimeUnit.YEAR, TimeZone.currentSystemDefault()).toEpochMilliseconds()
        val previousMonthInMilli = now.minus(1, DateTimeUnit.MONTH, TimeZone.currentSystemDefault()).toEpochMilliseconds()

       // Some processing of currentDateInMilli

       txtView.text = Instant.fromEpochMilliseconds(it).toLocalDateTime(TimeZone.currentSystemDefault()).format(dateFormatter)

Why is it the two sample behaves the same? I thought by passing TimeZone.UTC and TimeZone.currentSystemDefault()) when converting between Instant and LocalDate will set some offset based on provided timezone?

======================================================================================

UPDATE: It seems my actual question here is how to make KotlinX DateTime worked with library like Material DatePicker that requires Java 8 DateTime API?

It turns out that the MaterialDatePicker uses UTC time format, which means it doesn't contain any Time Zone information. We are getting correct behavior back when using Java 8 DateTime but after updating with KotlinX DateTime it is no longer working and hours behind.

I also tried the three approach here and they behave all the same yet on the UI level they behave differently.

[dkhalanskyjb]

Let's break down your original code.

        val dateFormatter = LocalDateTime.Format { // yyyy-MM-dd
            year()
            char('-')
            monthNumber()
            char('-')
            dayOfMonth()
        }

This is actually just LocalDateTime.Format { date(LocalDate.Formats.ISO) }.

        val now = Clock.System.now()

Here, you take the current moment. The one that happens right now.

        val currentDate = now.toLocalDateTime(TimeZone.UTC)

Here, you create a collection of fields—year, month, day, hour, minute, second—that the people in the Greenwich time zone see right now.

        val currentDateInMilli = currentDate.toInstant(TimeZone.UTC).toEpochMilliseconds()

Here, you convert currentDate back to now. Basically, you're asking: "What real moment corresponds to the point when the people in the Greenwich time zone observed these year, month, day, hour, minute, and second?" But that moment is just now (if there are no DST transitions, and for UTC, there aren't). This can be replaced with just now..toEpochMilliseconds(). In any case, currentDateInMilli is unused in the sample, so we can remove it.

        val oldestDateInMilli = now.minus(currentDate.year - 2009L, DateTimeUnit.YEAR, TimeZone.UTC).toEpochMilliseconds()
        val previousMonthInMilli = now.minus(1, DateTimeUnit.MONTH, TimeZone.UTC).toEpochMilliseconds()

Also seems irrelevant to the sample.

       // Some processing of currentDateInMilli

       txtView.text = Instant.fromEpochMilliseconds(it).toLocalDateTime(TimeZone.currentSystemDefault()).format(dateFormatter)

I don't know what's "it," so the example won't run as is, and you didn't explain what "it" is, so I can't help you with this code, sorry.

---

Now, let's look at the three approaches you've tried in Kotlinlang. They do not behave the same: the reason you see them behaving the same is that the timezone of play.kotlinlang.org is TimeZone.UTC. Running this in Europe/Berlin, I see

Java: 1721649261042
Java: 1719057261042
Kotlin Local: 1721642061047
Kotlin Local: 1719050061047
Kotlin UTC: 1721642061056
Kotlin UTC: 1719050061056

The numbers are clearly different between Java and Kotlin.

Here's what's going on in javaDateTime:

        val currentDate = LocalDateTime.now().atOffset(ZoneOffset.UTC)
        val currentDateInMilli = currentDate.toInstant().toEpochMilli()
        val previousMonthInMilli = currentDate.minusMonths(1).toInstant().toEpochMilli()

LocalDateTime.now() is equivalent to Kotlin's Clock.System.now().toLocalDateTime(TimeZone.currentSystemDefault()) and obtains the year, month, day, hour, minute, and second according to the clocks in the current time zone.

atOffset(ZoneOffset.UTC) then pretends that the LocalDateTime in the local time zone was actually in the UTC time zone and asks to perform all further arithmetics in UTC. It's not true, but that's what the code says.

So, the equivalent code in kotlinx-datetime is:

        val currentDate = Clock.System.now().toLocalDateTime(TimeZone.currentSystemDefault())
        val currentDateInMilli = currentDate.toInstant(TimeZone.UTC).toEpochMilliseconds()
        val previousMonthInMilli = currentDate.toInstant(TimeZone.UTC).minus(1, DateTimeUnit.MONTH, TimeZone.UTC).toEpochMilliseconds()

Does this answer your question?

[ArcherEmiya05]

Let's break down your original code.

        val dateFormatter = LocalDateTime.Format { // yyyy-MM-dd
            year()
            char('-')
            monthNumber()
            char('-')
            dayOfMonth()
        }

This is actually just LocalDateTime.Format { date(LocalDate.Formats.ISO) }.

        val now = Clock.System.now()

Here, you take the current moment. The one that happens right now.

        val currentDate = now.toLocalDateTime(TimeZone.UTC)

Here, you create a collection of fields—year, month, day, hour, minute, second—that the people in the Greenwich time zone see right now.

        val currentDateInMilli = currentDate.toInstant(TimeZone.UTC).toEpochMilliseconds()

Here, you convert currentDate back to now. Basically, you're asking: "What real moment corresponds to the point when the people in the Greenwich time zone observed these year, month, day, hour, minute, and second?" But that moment is just now (if there are no DST transitions, and for UTC, there aren't). This can be replaced with just now..toEpochMilliseconds(). In any case, currentDateInMilli is unused in the sample, so we can remove it.

        val oldestDateInMilli = now.minus(currentDate.year - 2009L, DateTimeUnit.YEAR, TimeZone.UTC).toEpochMilliseconds()
        val previousMonthInMilli = now.minus(1, DateTimeUnit.MONTH, TimeZone.UTC).toEpochMilliseconds()

Also seems irrelevant to the sample.

       // Some processing of currentDateInMilli

       txtView.text = Instant.fromEpochMilliseconds(it).toLocalDateTime(TimeZone.currentSystemDefault()).format(dateFormatter)

I don't know what's "it," so the example won't run as is, and you didn't explain what "it" is, so I can't help you with this code, sorry.

Now, let's look at the three approaches you've tried in Kotlinlang. They do not behave the same: the reason you see them behaving the same is that the timezone of play.kotlinlang.org is TimeZone.UTC. Running this in Europe/Berlin, I see

Java: 1721649261042
Java: 1719057261042
Kotlin Local: 1721642061047
Kotlin Local: 1719050061047
Kotlin UTC: 1721642061056
Kotlin UTC: 1719050061056

The numbers are clearly different between Java and Kotlin.

Here's what's going on in javaDateTime:

        val currentDate = LocalDateTime.now().atOffset(ZoneOffset.UTC)
        val currentDateInMilli = currentDate.toInstant().toEpochMilli()
        val previousMonthInMilli = currentDate.minusMonths(1).toInstant().toEpochMilli()

LocalDateTime.now() is equivalent to Kotlin's Clock.System.now().toLocalDateTime(TimeZone.currentSystemDefault()) and obtains the year, month, day, hour, minute, and second according to the clocks in the current time zone.

atOffset(ZoneOffset.UTC) then pretends that the LocalDateTime in the local time zone was actually in the UTC time zone and asks to perform all further arithmetics in UTC. It's not true, but that's what the code says.

So, the equivalent code in kotlinx-datetime is:

        val currentDate = Clock.System.now().toLocalDateTime(TimeZone.currentSystemDefault())
        val currentDateInMilli = currentDate.toInstant(TimeZone.UTC).toEpochMilliseconds()
        val previousMonthInMilli = currentDate.toInstant(TimeZone.UTC).minus(1, DateTimeUnit.MONTH, TimeZone.UTC).toEpochMilliseconds()

Does this answer your question?

Yes thanks a lot, now I understand the issue as I should be using currentDate for currentDateInMilli and previousMonthInMilli.

As for the sample where you are looking for it in Instant.fromEpochMilliseconds(it).toLocalDateTime(TimeZone.currentSystemDefault()).format(dateFormatter), it supposed to be the selection property from MaterialDatePicker which is the problematic part. Anyway thanks again!