[timeandmoney-discuss] Questions on Clock and Date arithmetic

[Vincent T. <vt...@py...>]

Hi,=20

We're seriously considering using the Time and Money library. The API is
very appealing and the implementation is great as well. For the first
time, I start to understand how instants, dates and time zones work
together ... Great work, really!

I've written a couple of unit tests against the 0.4.2 version to better
understand the behavior of instant and date arithmetic, and got a few of
questions.

1. TimePoint computations are affected by daylight saving, whereas
CalendarDate computations are not. So 1 month duration added to October
1st start of day EST gives me October 31st 23:00 EST. 1 month duration
added to October 1st (calendar date) gives me November 1st.=20

Is this on purpose? It seems that Java Calendar behaves like this as
well. I was surprised at first, but realized afterward that maybe
CalendarDate was the domain concept I should be using for this kind of
calculation, correct?

2. Clock does not define any default timezone. What is the rationale for
not using TimeZone.getDefault()?

3. I understand that to preserve encapsulation, getters are not provided
to access internal states of objects, e.g. there is no way to get the
quantity and unit of Duration. This is causing me some headaches as
regards to persistence. Money, on the other hand, provides
breachEncapsulationOfXXX() methods. I had to rely heavily on reflection
to write Hibernate UserTypes for Duration, TimePoint, CalendarDate,
TimeInterval and CalendarInterval. Getters would have been really useful
there. Is there any plans to provide getters in the future to accomodate
ORM engines? Default constructors would be great as well (they don't
have to be public though), to support Hibernate Custom Types.

Thanks,
-- Vincent