On Thu, Feb 16, 2017 at 4:48 PM, Guillaume Smet <guillaume.smet(a)gmail.com>
wrote:
Hi Michael,
On Thu, Feb 16, 2017 at 7:29 PM, Michael Nascimento <misterm(a)gmail.com>
wrote:
>
> Since Duration is really just seconds and milliseconds and any conversion
> is always flat (in the sense it doesn't take into account daylight savings
> time, for instance), I find it way less useful to support than Period and
> arbitrary TemporalAmounts (such as
http://www.threeten.org/thr
> eeten-extra/apidocs/org/threeten/extra/Days.html ).
>
The first PR of Marko contained the Period support. The issue is that
Period is not comparable and there is no easy way to compare 2 periods so
we decided to not implement it for now. The typical issue we had is how do
you compare 1 month and 30 days.
You don't compare, because they are not the same. The idea is that the
Period must be defined in terms of the units for which you defined its
boundaries.
As for supporting threeten-extra, it wouldn't be done in the spec
anyway.
You shouldn't support threeten-extra, but rather arbitrary TemporalAmounts.
Then threeten-extra just happen to be one of those. There must be something
like @ChronoUnitMax/@ChronoUnitMin such as:
@ChronoUnitMax(unit=DAYS, value=1)
As I said, I'm open to provide input, I was just surprised this support was
not discussed as part of the spec itself and prototyping work started right
way (in the less useful class for business applications, in my opinion).
Regards,
Michael