Open zivkovic opened 1 month ago
Thanks for your suggestions. Most of them look good, and I'll try to implement them when I get time later, as I'm a bit busy right now with another project.
I see you are still using java in the project. Might be nicer to have this library Kotlin only, and not dependent on java. Kotlin-datetime could maybe be used? Since I saw "Kt" in the project name, I thought you only used kotlin (like it is claimed in highlights: "Lightweight with no external dependencies other than kotlinx:kotlinx-coroutines-core from the Kotlin standard library."). Not a problem for my use case, but still if it would be kotlin only, it would be kotlin multiplatform compatible.
The thing is, the Kotlin datetime library has many missing features that you need to implement yourself, and it isn't as comprehensive as the java.time.*
library. The main use case of this library is in backend applications where none of the frameworks use Kotlin/Native. Honestly speaking, Kotlin/Native isn't widely used anywhere; you always use Kotlin on the JVM platform for such tasks. Therefore, using kotlin.datetime
doesn't offer many benefits here and only complicates things while adding another potential point of failure. Datetime APIs are naturally delicate, and I try to avoid any custom implementation as much as possible.
Documentation has some issues. Open link and click on any other trigger. It opens a "not found" page.
That's actually an old issue with JitPack. See https://github.com/jitpack/jitpack.io/issues/3295. I can't really do much from my side about that :(
Thanks for the quick response. Sounds good.
Just tried using the library and hit a couple of problems or areas which could/should be improved.
trigger.getNextRunTime(ZonedDateTime.now(timeZone), timeZone)
in the underlying code and not force the user to set it up.Documentation has some issues. Open link and click on any other trigger. It opens a "not found" page.
Hopefully I didn't criticize too much.
Thanks!