24.hour.millis get 86400000 but 1.day.millis get 0

[Renkai]

code

import com.github.nscala_time.time.Imports._
24.hour
24.hour.millis

1.day
1.day.millis

results:

import com.github.nscala_time.time.Imports._
res0: com.github.nscala_time.time.DurationBuilder = com.github.nscala_time.time.DurationBuilder@fef68c09
res1: Long = 86400000

res2: org.joda.time.Period = P1D
res3: Int = 0

[kmizu]

Hi.

The above behavior is confusable. But I think it's intended behavior. See below:
https://github.com/nscala-time/nscala-time/blob/releases/1.8.0/src/main/scala/com/github/nscala_time/time/RichInt.scala#L34-L41

[wookietreiber]

But 1.day.millis === 0 can't be correct, can it?

I guess, whether this behaviour is intended or not, it should be in a Spec-like test somewhere (don't know if it already is) so people can see the expected behaviour.

[gakuzzzz]

I agree that 1.day.millis === 0 is confusable.

Essentially problem is there is no way of representing day, week, month, year and etc to Duration.

We should provide another DSL what builds Period and Duration explicitly.

[wookietreiber]

Ah, OK, now I get it: period.millis returns the milliseconds part of the period, while duration.millis returns the duration in milliseconds (I just had to check the joda time API docs, because I was confused). So, 1.day.millis === 0 is in fact correct.

I wonder, what could be done to make this not as confusing as it is right now to users. The DSL should definitely make it clear whether you get a duration or a period, while the user still has to figure out the exact differences between the two for herself/himself.

// compiles
1.period.day
24.duration.hours

// does not compile
1.duration.day

This would help although it feels a bit more clumsy. I guess, tradeoff between concise DSL vs. clearer DSL.

I vote to change the DSL because the issue not only entails user confusion but even erroneous apps / libs because of the wrong assumption that 1.day.millis != 0.