I am looking at removing java date/time from my co...

# stdlib

[jimn]

I am looking at removing java date/time from my code where it is almost painless.

in the matter of java Instant ctor, and serialization, we need 12 bytes, a long for ms and int for nanos.

The kotlin Duration analog class only appears to support at best a Long or Double, neither which supports the same resolution. Instead of a break between Java's Date, DateTime, and Instant classes which supports DateTimes with nanosecond backingstores, Duration apparently presumes to do all three and for events on astronomical scales of time resolution appears to force the coder to box a relative 64 bit expanse of measurement for the non-jvm stdlib.

to my understanding BigInteger math is a sliding set of 32 bit Int operations going up and down to MAXINT resolution and is claimed to be faster in the C2 on intel than native wide instructions in some cases.

Is Duration with a promotion option to BigInteger backingstore reasonable?
The solution would address
a) usecases that want higher res, and
b) a sideload BitSet/BigInt serialization option that can match impedences with e.g. Instance and other DateTime libraries which don't all apparently assume 64 bits and only 64 bits.

[ilya.gorbunov]

If you're using kotlinx.datetime, you can construct Instant from Long number of seconds and Int number of nanoseconds using this function: https://github.com/Kotlin/kotlinx-datetime/blob/v0.3.0/core/common/src/Instant.kt#L122

[ilya.gorbunov]

If you want to construct a Duration from Long seconds/milliseconds + Int nanoseconds, you can just build these parts separately and add them together using plus operator. However, if the Duration value exceeds 146 years, its precision becomes limited to milliseconds.
In general, we don't recommend using Duration where Instant is required and do not consider such use cases valid for Duration. Therefore, we're not considering promoting the backing property of Duration to BigInteger either.

[jimn]

fair tradeoff for non-scientific usecases. I would suggest a zigzag numbering stdlib alt that is tailored to 7/63/variable bit serialization to satisfy 10000 year long-now foundation widgets 🙂

[jimn]

the alternative is dealing with some nonstandard dataclass of years+precision