Hi all, I don't think this is strictly related to ...

# kotlinx-datetime

[ste]

Hi all, I don't think this is strictly related to kotlinx.datetime in particular, however...
I put some extension methods (e.g. LocalDate.Companion.now()) in a KMM module (:utils:datetime) under the package kotlinx.datetime, so that I can seamlessly use my extensions from the whole code base.
Well, I don't know whether this is a good practice or not; but during build time, Gradle can't see some methods of the original kotlinx.datetime (on the other hand, no errors from the IDE).

For instance, it complains about

public expect operator fun LocalDate.minus(period: DatePeriod): LocalDate

...as it thinks it's

public expect fun LocalDate.minus(value: Int, unit: DateTimeUnit.DateBased): LocalDate

However, if I rename my kotlinx.datetime to something else, or use the latter method, it works... What am I missing here?

[Adam S]

what’s the actual error message?

[ste]

state.journal.date - DatePeriod(days = 1)


e: No value passed for parameter 'unit'
e: 'operator' modifier is required on 'minus' in 'kotlinx.datetime'
e: Type mismatch: inferred type is DatePeriod but Int was expected

[Adam S]

it’s hard to think what the problem might be from that. What’s the full error? Is there a stacktrace? What Gradle task do you run? What version of Kotlin and Gradle are you using? Do you have build cache and config cache enabled? Does clearing the caches change anything? Is it only a problem for one Kotlin target, or multiple?

[ste]

There's no "full" error or anything in particular (it's a plain compilation error, no stacktrace), it really is as if I were using a method that doesn't exist.

Tasks are compileDebugKotlin (from Android module)/`compileKotlinJvm` (from KMM module)...
Already toggled config cache, invalidated cache etc.

Kotlin 1.8.21, Gradle 8.1.

All I have to do to trigger the error is adding a dependency to my utils module:

implementation(libs.kotlin.datetime)
implementation(projects.utils.datetime)

[ephemient]

if you created a class with the same package+name as another existing class, only one will be visible in the classpath, and it's not well-defined which one it'll be

[ste]

I didn't create a class, there are only extension methods

[ephemient]

convention in the JVM world is that packages should not be split across jars

[ephemient]

top-level functions are implemented by a hidden static class

[ste]

Yeah you are right. I used the same file name (LocalDate.kt), so it ended up creating a class with same package+name. Thanks!