ilya-g

Thanks for noticing this. It looks like a problem in Kotlin plugin, I've reported it as https://youtrack.jetbrains.com/issue/KT-41317

An important difference is that bootstrap builds are persisted indefinitely because Kotlin build have used them at some point, whereas dev builds are not persisted and can be deleted at...

Related issue: https://youtrack.jetbrains.com/issue/KT-19805

@JWood48, what are you going to represent with such a class? It's important to consider use cases to design the proposed type properly.

In Maven JVM projects you should depend explicitly on `kotlinx-datetime-jvm` variant, like you do with any other Kotlin/MPP library. I don't know the details behind `@file:DependsOn` dependency resolution mechanism, but...

The class name `j$.time.ZoneOffset` indicates that the java.time classes were desuraged. What I know about this process is that it links the desuraged API classes in a separate .dex. Maybe...

In JDK 8, which this library targets to on JVM, `java.time` does not support parsing such format by default: neither `Instant`, nor `OffsetDateTime` can do it. Perhaps it was supported...

@merlin-zaraza We expect a string in the extended ISO format of complete representation for calendar date and time of day (ISO 8601-1:2019, clause 5.4.2.1) as an input of the `Instant.parse`...

@merlin-zaraza Currently there's no way to parse such values because `Instant.parse` doesn't support this format. Later, when we implement custom formatting and parsing (see #58, #39), you'll be able to...

@dkhalanskyjb In the basic format, date and time parts are also written without delimiters, e.g. `20210120T231501+0400`. I suppose it's not what is needed here.