Marc Knaup
05/25/2021, 3:25 PMkotlinx-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
05/26/2021, 4:01 AMDuration.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-45325kotlinx-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
05/26/2021, 3:20 PM.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
05/26/2021, 7:03 PMMarc Knaup
05/26/2021, 7:04 PMlouiscad
05/26/2021, 7:13 PM