How do you guys work with LocalDateTime and all it...

# kotlinx-datetime

[kalpeshp0310]

How do you guys work with LocalDateTime and all its siblings on the Native side?
I have models in my multiplatform app’s common code, with fields with LocalDate type. It’s a pain to create an instance of Kotlinx_datetimeLocalDate from Swift, and iOS developers do not feel comfortable working with it.

[Dmitry Khalanskiy [JB]]

I'm not working with LocalDateTime as much as I work on it, so I may be unable to help you. Rather, you can help us 🙂

It’s a pain to create an instance of Kotlinx_datetimeLocalDate from Swift

Isn't it enough to just call its constructor with the proper numeric values? Is it somehow worse than creating an instance of any other Kotlin class from Swift?

iOS developers do not feel comfortable working with it.

What kind of work do they struggle with? Are there any specific examples of pain points?

We also have some converter functions: https://kotlinlang.org/api/kotlinx-datetime/kotlinx-datetime/kotlinx.datetime/to-n-s-date-components.html Maybe it makes sense to convert LocalDate to NSDateComponents and work with that, populating a LocalDate when converting back?

[kalpeshp0310]

Thanks a lot for your reply. And I think I unintentionally exaggerated the issue. Also, we started exploring KMM a few weeks back and might not be looking at the right thing.

I meant to say there is no easy way to Convert LocalDateTime to `NSDate`; the conversion function you mentioned is not available on the swift side. Those are only accessible from Kotlin files under the native src directory. And the other reason is the Long name Kotlinx_datetimeLocalDate. I understand we are nitpicking. But if the names had been the same on both platforms, Like LocalDate on JVM and Native side, they would feel like they are using just another Library and would not be constantly reminded that they are using Kotlin multiplatform library.
I guess the recent introduction of @ObjCName can solve the issue of the long name.

[kalpeshp0310]

To explain our case, We have an Event class with an eventDate field of LocalDateTime type. To consume that field and show the event date in UI, iOS devs need to convert that LocalDateTime to Date or NSDate type and then convert it to `String`; Of course, we can use an extension function to simplify conversion. But wanted to see what other people were doing in this case.
There is the reverse case as well, where a user selects a date from the calendar UI, which gives a Date object, and they have to convert it from the Date type to the LocalDateTime type before calling the createEvent function from our common code.

I am not saying that it’s not doable. But it constantly reminds iOS developers that they are not talking to Swift library; They are talking to a library written in kotlin. This is a slight pain when the iOS team resists adopting/working with a library not written in Swift.

[Dmitry Khalanskiy [JB]]

Convert LocalDateTime to NSDate

There's a conceptual confusion here: an equivalent to NSDate is kotlinx.datetime.Instant. And we do have NSDate.toKotlinInstant / Instant.toNSDate.

the conversion function you mentioned is not available on the swift side

I think you're just a victim of dead code elimination. With some effort, you'll be able to access these functions. See https://github.com/Kotlin/kotlinx-datetime/issues/78#issuecomment-740573900

To consume that field and show the event date in UI

I personally am diligently working on the formatting capabilities in kotlinx.datetime right now, stay tuned, maybe you'll be able to format dates in KMM common code soon.

But it constantly reminds iOS developers that they are not talking to Swift library

Yep, the truth is, they are not. I'm just a library writer and not a KMM expert—if you want one of those, ask around in #multiplatform—but my personal understanding is that our libraries are not supposed to be treated as libraries for every platform. Instead, these are libraries for Kotlin code, and in turn, that Kotlin code can be used on different platforms. So, essentially, the idea is to write the whole thing in Kotlin, except the UI and the other interactions with the platform. For example, in your case, there could be some code in the Native source set that would accept an NSDate and call createEvent with that, using the conversion function and keeping the fact that the Kotlin implementation uses kotlinx.datetime completely hidden from the (small) Swift wrapper around the Kotlin-based functionality.

Still, I advise asking around #multiplatform regarding usage of Kotlin libraries directly from the platform code would certainly be more useful than my ramblings, as there are people there that actually have some experience with this. Sorry for the wall of text, I just didn't want to send you away empty-handed 🙂

[kalpeshp0310]

Thanks a lot for taking the time to explain. 🙏
A lot of what you are saying makes sense. I tried to explore a few open-source projects, and they are doing what you suggested.