Is there a library function to compute the factional hours/minutes/.. from a kotlin.time.Duration? ChatGPT suggests val fractionalHours: Double = duration.inMinutes / 60.0 but I feel this should be something reoccurring and thus a candidate for the library.

Consider reading the documentation instead of asking ChatGPT. it's explained in the text: https://kotlinlang.org/api/latest/jvm/stdlib/kotlin.time/-duration/

Also Duration is part of the stdlib, not kotlinx-datetime library

Thanks. I had the vague memory of such a function as well. But the IDE is not showing completion for it and the compiler also does not know about it:

Well first, the IDEA does show auto-complete for it… it's even the suggestion you have highlighted in your screenshot. Regarding

inDays

: read its documentation 🙂

It seems

toDouble(DAYS)

is the new API. Not sure why it feels so much more complicated as

inDays

.

Sure, but wholedays is giving by design a different result, it's not a fractional quantity.

Let's not be harsh! If everyone actually read the documentation, half the messages in this Slack and in the issue trackers for the libraries would disappear, and with them, the invigorating feeling of a bustling community.

The method inDays has been hidden,

, errorSince = "1.8", hiddenSince = "1.9"

see https://github.com/JetBrains/kotlin/blob/7a7d392b3470b38d42f80c896b7270678d0f95c3/libraries/stdlib/src/kotlin/time/Duration.kt#L809

@holgerbrandl, it's interesting that you need Double values. From what we've seen, methods that return integral numbers are much more in demand. One uses integral numbers for • showing the values to the end user, • calculating delays (by converting to the most granular value without missing precision, e.g.

Thread.sleep(inWholeMilliseconds)

), • doing precise arithmetic operations on Duration values, • etc. This is why

inWholeDays

is much more prominent than

toDouble(DAYS)

. What are you doing with

Duration

values that needs floating-point numbers?

@Dmitry Khalanskiy [JB] I'm mirating a simulation library www.kalasim.org (presented at last KotlinConf) from previously used custom types to track simulation time (called

org.kalasim.TickTime

, to use kotlin.time.* instead. Generally this helps a lot to improve readability and type-safety. As part of the process, I deal a lot with fractional durations which are sometimes easier to use for me when expressing duration amounts. Since they did not do any harm and were part of stdib I was just curious why they had been removed. But clearly if nobody was using them, It's easy to bring them back in my library. I just wanted to double check that I did not miss anything before reimplementing the wheel. Thanks everyone for your support in this thread.

Interesting! I've skimmed through your talk and now have some understanding of what this is about. I'm wondering how your usage of floating-point numbers affects the resulting product. I can see several options: • It makes the calculations less precise than if you used integral numbers, making the results less reliable. • It reflects the fact that in real life, time measurements are not precise but are, most of the time, slightly off, and make the results more aligned with reality. • It helps the simulation avoid unpleasant artifacts that may occur when several processes are scheduled at exactly the same moment, causing some instability in edge cases. • It doesn't affect literally anything at all due to how negligible the error is. This seems the most likely to me. If, after finishing your migration to

Duration

, it turns out that something suddenly got significantly better or significantly worse, it would be great if you left some feedback.

Sorry, I reacted too strongly here. There has been an increase of people asking obvious questions based on incorrect information given by ChatGPT, and I thought it was one of these. It wasn't, and now I'm the one polluting the discussion 😕

Can relate. For me, too, mentioning ChatGPT is a pretty strong indicator that the question is inane. "This code provided by ChatGPT doesn't work" stopped being entertaining and started to be irritating a while ago already.

You got it totally right Dimitry. Indeed precision and deterministic behavior are key design considerations in simulations. I mainly use fractional durations when studying stochastic processes. To answer questions such as "On average how long does it take to serve a customer/patient", which previously were expressed with some double fraction. But I understand and share your argument, that this may lack precision and lead to rounding issues. Sure, I can report back in here how the migration worked once completed.

I have no input on the actual problem at hand here but I just wanted to give everyone a pat on the back for handling the social tension like mature people. Good demonstration of humility all around. It really shows why this community is awesome!

Hopefully this is relevant, but does Duration.toComponents help here? It splits a duration into its day, hour, minute, second, and nanosecond components. https://kotlinlang.org/api/latest/jvm/stdlib/kotlin.time/-duration/to-components.html