hernan gonzalez <hgonzalez(at)gmail(dot)com> wrote:
> I believe that this distinction between two realms: one related to
> (say) "physical time" and the other to (say) "civil date-time", is
> the key to put some order... conceptually, at least (I'm not
> speaking about feasibility for now). This is the approach of some
> Date-Time APIs, for example the "Joda" Java library
> http://joda-time.sourceforge.net/ (headed to replace soon
> https://jsr-310.dev.java.net/ the original ugly JDK
Date-Calendar
> API) and I believe it's the right way.
Congratulations on the most sane and thoughtful discussion of this
I've seen! In our shop we had so many problems with the "physical
time" based implementation of dates, times, and timestamps in Java
that we wrote our own library to cover our needs. I hadn't heard
about Joda; we should probably look at it to see if we can migrate
from our home-grown solution.
One thing you didn't address is the "end-of-month" issues -- how do
you handle an order that someone pay a set amount on a given date and
monthly thereafter, when the date might be past the 28th? I'm curious
to hear your opinion on that topic. I have seen in this real-world
financial applications several times. They have usually wanted to go
to the last day of the month when there aren't enough days in a given
month, but then go back out to the original day-of-month whenever
possible; but sometimes the payment "one month" after the 31st of
January has to be 30 days past the 1st of the next month. The SQL
standard solution to this is much ridiculed here, even though I
suspect many have seen monthly bills or statements at some point in
their lives.... ;-)
-Kevin