Implement the same ranges for all platforms #453
Conversation
core/common/src/LocalDate.kt
Outdated
| @@ -471,7 +473,7 @@ public expect fun LocalDate.plus(value: Int, unit: DateTimeUnit.DateBased): Loca | |||
| * @throws DateTimeArithmeticException if the result exceeds the boundaries of [LocalDate]. | |||
| * @sample kotlinx.datetime.test.samples.LocalDateSamples.minus | |||
| */ | |||
| public expect fun LocalDate.minus(value: Int, unit: DateTimeUnit.DateBased): LocalDate | |||
| public fun LocalDate.minus(value: Int, unit: DateTimeUnit.DateBased): LocalDate = plus(-value.toLong(), unit) | |||
There was a problem hiding this comment.
it might be a good idea to use parenthesis here, because of this:
val value = Int.MIN_VALUE
println( -value.toLong() ) // 2147483648
println( -(value.toLong()) ) // 2147483648
println( (-value).toLong() ) // -2147483648
core/common/src/LocalDate.kt
Outdated
| @@ -344,7 +350,7 @@ public operator fun LocalDate.minus(period: DatePeriod): LocalDate = | |||
| * - Negative or zero if this date is later than the other. | |||
| * - Exactly zero if this date is equal to the other. | |||
| * | |||
| * @throws DateTimeArithmeticException if the number of months between the two dates exceeds an Int (JVM only). | |||
| * @throws DateTimeArithmeticException if the number of months between the two dates exceeds an Int. | |||
There was a problem hiding this comment.
Is this still true now that DatePeriod.totalMonths is a Long?
dkhalanskyjb
force-pushed
the
uniform-ranges
branch
from
0f69a99
to
74cbbe3
Compare
dkhalanskyjb
force-pushed
the
uniform-ranges
branch
3 times, most recently
from
b7c293c
to
ae4373e
Compare
dkhalanskyjb
force-pushed
the
uniform-ranges
branch
from
ae4373e
to
e1a2c61
Compare
| * @see LocalDate.fromEpochDays | ||
| * @sample kotlinx.datetime.test.samples.LocalDateSamples.toEpochDays | ||
| */ | ||
| public fun toEpochDays(): Int | ||
| public fun toEpochDays(): Long |
There was a problem hiding this comment.
Have you considered retaining source and/or binary compatibility?
There was a problem hiding this comment.
We didn't find a way to choose an overload based on its return type, so we can't restore source compatibility. Also, on Native, the binary compatibility can't be restored, as two signatures with different return types cause a compilation error.
Restored the binary compatibility for the JVM.
| zones[components[0]]?.let { rules -> | ||
| zones[components[1]] = rules | ||
| } |
There was a problem hiding this comment.
Is the order of the two time zones specified? I mean is it possible that the second time zone has rules but the first doesn't?
There was a problem hiding this comment.
https://momentjs.com/timezone/docs/#/data-formats/link-format/ doesn't say anything either way, so the js-joda implementation is the best guidance we have on this, and they do assume this order.
| } catch (e: IllegalArgumentException) { | ||
| throw DateTimeArithmeticException("Boundaries of LocalDate exceeded when adding a value", e) | ||
| } | ||
| public actual fun LocalDate.plus(unit: DateTimeUnit.DateBased): LocalDate = plus(1, unit) |
There was a problem hiding this comment.
Nit: Can the implementation be moved to the common source set?
There was a problem hiding this comment.
I don't think so. The JVM overload is in @file:JvmName("LocalDateJvmKt"), and moving it to LocalDateKt would be a breaking change. We could keep a LowPriorityInOverloadResolution DeprecationLevel.HIDDEN copy in LocalDateJvmKt, but then what's the point in moving it to common code? It's deprecated anyway.
Fixes #432