Provide built-in Serializers for commonly used formats

[janseeger]

Inheriting from FormattedInstantSerializer works, but needs to be repeated in every codebase.

Also InstantComponentSerializer as of now doesn't have a replacement (yet) in kotlinx.serialization.

[dkhalanskyjb]

needs to be repeated in every codebase

That's literally a couple of lines of code:

kotlinx-datetime/core/common/src/serializers/LocalDateSerializers.kt

Lines 21 to 22 in 1953358

	public object LocalDateIso8601Serializer : KSerializer<LocalDate>
	by LocalDate.Formats.ISO.asKSerializer("kotlinx.datetime.LocalDate/ISO")

InstantComponentSerializer

It can't currently be replicated with FormattedInstantSerializer anyway.

[janseeger]

That's exactly why I raised this issue: I would have expected Kotlin Time supporting common formats out of the box already. As in, no custom Serializer and Serializable(with=) override needed.

About the InstantComponentSerializer thing, it would have been nice to publish the replacements before deprecating and moving the old ones. Now we have to migrate the types and then the Serializers in a second step (both being breaking changes).

[chrisjenx]

It is confusing, the deprecation note suggests to use the built-in kotlin.time / std lib serializers, but from what I can see, these don't exist in either code base?
Was the intention they would have shipped included serializers first before this release?

[dkhalanskyjb]

That's exactly why I raised this issue: I would have expected Kotlin Time supporting common formats out of the box already. As in, no custom Serializer and Serializable(with=) override needed.

The serializers are going to be available in the next kotlinx.serialization release: Kotlin/kotlinx.serialization#3026 This should cover your need. When it happens, are you still going to want kotlinx-datetime to include built-in KSerializers for commonly used formats?

it would have been nice to publish the replacements before deprecating and moving the old ones

I don't think it makes sense to postpone a kotlinx-datetime release to wait for a kotlinx.serialization release to provide the serializers. Some people are interested in other functionality and are not blocked by the serializer availability.

What was a clear mistake on our part is that we didn't communicate that serializers were not available yet, but will be in the next kotlinx.serialization release. I'm sorry for the confusion.

Now we have to migrate the types and then the Serializers in a second step (both being breaking changes).

If you were using default kotlinx.datetime.Instant serializers, without any overrides, then to make this second step after migrating to kotlin.time.Instant, it will be enough to update kotlinx.serialization.

[janseeger]

My response might have come across a bit harsher than intended.

I totally understand not wanting to wait with the release, and on the other hand it is my fault to migrate immediately to kotlin-time, thus having to do the migration twice.

[chrisjenx]

Ok that's good to know it was a bit confusing.
Probably would have been good to add a note about the serializers to the release notes. Hopefully for the most part people read those.

I agree on not holding back releases, I think a case like this might of made sense to be an rc/alpha while waiting for the other libs to catch up. It sets the expectation a bit better that it's not "ready"

[chrisjenx]

Also looks like they cut a release. Nice

[solonovamax]

The serializers are going to be available in the next kotlinx.serialization release: Kotlin/kotlinx.serialization#3026 This should cover your need. When it happens, are you still going to want kotlinx-datetime to include built-in KSerializers for commonly used formats?

this is not a solution because InstantSerializer is marked as internal and a class marked as @Serializable with an Instant property reports an error because it cannot locate the serializer for Instant. Because InstantSerializer is marked as internal, you cannot add @Serializable(with = InstantSerializer::class) to the property.
there is no way to work around this other than adding your own serializer.

[dkhalanskyjb]

@solonovamax, marking anything with @Serializable(with = InstantSerializer::class) shouldn't be necessary.

To use kotlinx.serialization 1.9.0, you have to be on Kotlin 2.2.0 (see https://github.com/Kotlin/kotlinx.serialization/releases/tag/v1.9.0), which includes this commit: JetBrains/kotlin@6869122 With it, Instant should behave just like Int or Long, which are serializable by default.