Hey there! What is the easiest way to parse an ISO...

# serialization

[Marc Reichelt]

Hey there! What is the easiest way to parse an ISO8601 date right now with kotlinx serialization?

[basher]

we have an expect class for a date object, which has methods for parsing a string into that date. From there, you can make a custom serializer that users your expect class

[Marc Reichelt]

Thanks - I thought of that road, but then I would have to implement the parsing myself somehow (or find out how to do that on iOS as well)

[Marc Reichelt]

I got it working now using the lib https://github.com/erikc5000/island-time by @Erik Christensen and using a custom serializer

[Marc Reichelt]

@Serializable
data class GitHubRepo(

    @SerialName("name")
    val name: String,

    @SerialName("stargazers_count")
    val stargazersCount: Int,

    @SerialName("created_at")
    @Serializable(with = ZonedDateTimeSerializer::class)
    val createdAt: ZonedDateTime,

    @SerialName("language")
    val language: String?
)

@Serializer(forClass = ZonedDateTime::class)
object ZonedDateTimeSerializer : KSerializer<ZonedDateTime> {

    override val descriptor: SerialDescriptor =
        StringDescriptor.withName("ZonedDateTime")

    override fun deserialize(decoder: Decoder): ZonedDateTime {
        return decoder.decodeString()
            .toOffsetDateTime()
            .asZonedDateTime()
    }

    override fun serialize(encoder: Encoder, obj: ZonedDateTime) {
        encoder.encodeString(obj.instant.toString())
    }
}

[basher]

Ah yep makes sense 👍

[Marc Reichelt]

it’s still in early preview, but I like it gives me the same classes I so like from the java.time api

[Erik Christensen]

If you're storing an Instant, you could read it out using just using String.toZonedDateTime(DateTimeParsers.Iso.Extended.INSTANT) I think. Just keep in mind that if you're serializing and unserializing that way, you lose the time zone. The ZonedDateTime will have a fixed offset zone at UTC. That may or may not be what you want.

[Marc Reichelt]

That’s ok for me right now - I actually only care about deserializing the JSON, not serializing it back 🙂

[Erik Christensen]

Fair enough.

[Erik Christensen]

At some point, I think it'd be nice to have an additional package that has some standard serializers for Kotlinx serialization for string and binary formats.

[Erik Christensen]

It's nice to see people trying to people trying the library out already. If you have any feedback or bug reports or anything, please let me know.

[Marc Reichelt]

yep, I have some feedback

[Marc Reichelt]

1) I had to include the stately libraries in my build.gradle.kts (and enable Gradle metadata), otherwise it wouldn’t compile

[Marc Reichelt]

2) It’s a little unexpected to have both an arm64 as well as a x64 variant for iOS - I would expect to only include one dependency (my build would fail now on a device, because I just use the simulator for demo purposes)

[Marc Reichelt]

3) ZonedDateTime didn’t implement Comparable - but I could easily build a Comparator myself

[Marc Reichelt]

Apart from that, I think it’s a really cool library

[Marc Reichelt]

- gives me exactly the API I want ❤️
- pretty easy to set up
- yay, multiplatform!

[Marc Reichelt]

@Erik Christensen I think this is a great library, and I really hope you keep working on this. Hopefully my feedback can help to make it easier for users!

[basher]

For 2, why would an x64 variant not be included?

[basher]

To clarify, all supported variants should be included, and gradle module metadata should sort out including the variants you need

[Erik Christensen]

1) I heard that from someone else too -- still need to figure out why that's happening. 2) What Ben said.

[Marc Reichelt]

My project is a sample project accessing the GitHub API, and you can see it here: https://github.com/mreichelt/github-api-kotlin-multiplatform

[Erik Christensen]

3) That's a deliberate design decision. In java.time, OffsetDateTime and ZonedDateTIme implement Comparable based on a natural ordering that isn't quite the same as timeline order. That makes it consistent with equals, but can also be a source of subtle bugs since comparison with < or > isn't based just on timeline order as one might expect. To compare based on timeline order, you have to use isAfter(), isBefore(), or is isEqual() or use toInstant().

Island Time forces you to be explicit about what ordering you want -- there are DEFAULT_SORT_ORDER and TIMELINE_ORDER comparators on OffsetDateTime and ZonedDateTime. The first will avoid non-determinism when sorting. The second will consider just timeline order.

At least right now, compareTo() is also implemented as a Kotlin operator and it will let you compare based on timeline order using < or >. That's not quite consistent with equals, but maybe more what one would expect?

For more on the debate that went on about this during the development of java.time: https://blog.joda.org/2012/11/pitfalls-of-consistent-with-equals.html

[Marc Reichelt]

@basher and @Erik Christensen: I would expect one ios dependency with all CPU architectures? Other multiplatform libs (okio, ktor-client, …) support multiple CPU architectures.

[Marc Reichelt]

@Erik Christensen ok, that actually makes sense (regarding sort order) - it was a really small thing anyway 🙂

[basher]

You should only have to specify it once in your commonMain dependencies, and then gradle metadata sorts it out from there

[Erik Christensen]

Yeah, I was just looking at the project -- if using Gradle module metadata, you should be able to just use the common artifact

[Erik Christensen]

@Marc Reichelt: FYI - The Stately dependency issue is fixed now and I updated the README instructions to encourage using just the common variant of the core artifact