Inconsistent: `kotlinx-datetime` `Instant`, `Loca...

# kotlinx-datetime

[Marc Knaup]

Inconsistent:

kotlinx-datetime Instant, LocalDate, etc.
• uses ISO-8601 for `toString()`/`parse()`
• provides serializer

kotlin.time Duration OTOH
• uses human-readable output for toString(), returns ISO-8601 for toIsoString(), and has no parse()
• has no serializer

Still two different date/time worlds in Kotlin and usage is confusing and error-prone.

[ilya.gorbunov]

We want to change the format of Duration.toString but it will still remain human readable, not based on ISO (https://youtrack.jetbrains.com/issue/KT-42851)
We also have Duration.parse in near plans, that would support both that human-readable and the ISO formats: https://youtrack.jetbrains.com/issue/KT-45325

[ilya.gorbunov]

Regarding the serialization, we'll probably support it in kotlinx-serialization for Duration as we support it for other built-in types, because we can't do it other way around: stdlib cannot depend on kotlinx-serialization

[Marc Knaup]

Thanks @ilya.gorbunov.

So, .toString() is supposed to lose precision to make it human-readable. .parse() is supposed to parse the human-readable format. That would make the result d2 = Duration.parse(d1.toString()) very confusing because often d1 != d2.

The toString() (& parse()) issue is a general issue in Java and now Kotlin.
Is toString() supposed to return a human-readable or a machine-readable result?
Human-readable involves many aspects like locale, precision, time zone, etc.
While machines can always serialize and parse consistently (e.g. ISO 8601).

Same discussion with Double.toString() - locale-dependent or not?

I’d argue to implement toString() for fundamental types consistently. Either always for humans or always for machines. Never mixed. Then developers always know what to expect.

And parse() should never try to parse two different formats. If I build an API that expects an ISO 8601 duration then I don’t want it to accept some human-readable format too just because Kotlin happens to do so.

[louiscad]

There's human readable, machine readable, and in the middle, sits developer readable. The problem with toString in Java is that it's sometimes one, sometimes another, and that leaks into Kotlin.

[Marc Knaup]

Yes. That’s why it would be nice if Kotlin would focus on increasing consistency and predictability here.

[louiscad]

The consistency is currently to have none 😅