Re: [boost] [date_time] boost time lacking tic-tac

From: Joachim Faulhaber (afojgo_at_[hidden])
Date: 2008-05-22 18:42:17

2008/5/22, James Porter <porterj_at_[hidden]>:
> On Thu, May 22, 2008 at 3:56 PM, Joachim Faulhaber
> <afojgo_at_[hidden]> wrote:
> > Incrementability seems also more fundamental to me than Addability.
> > Which is to say that a concept or algebra that offers Addability
> > almost certainly also has a Incrementability, but not the other way
> > round. Take for instance the Peano Axioms of natural numbers, where
> > Incrementability is given in the form of the fundamental successor
> > function.
>
> Not necessarily true. Strings under concatenation (a monoid) are
> Addable, but incrementing makes little sense.

only syntactically an Addability, semantically rather Concatenatablity
(strange word ;-) But you are right. I focused too much on integral
numerical types.

> Further, incrementing on
> even the real numbers doesn't necessarily make sense,

therefor my interval containers provide a different implementation for
continuous types that does not require incrementation.

> at least not
> when defined in terms of the successor function (which maps integers
> to integers). Complications also arise in, well, complex numbers. ;)
>
> Dates/times are a more unusual case because their underlying
> representation is integral, but as a physical concept they are
> continuous (as far as we know). Questions arise especially when
> considering the granularity of the date/time you are dealing with. Is
> foo_date+1 24 hours from now, or one second from now? Or perhaps one
> millisecond...
What I've learned is that in boost::date_time, this is handled via
different duration types

time_type operator+=(const date_duration_type& dd);
time_type operator+=(const time_duration_type& td);

which is nice. Yet as for date/time parameters for my interval and
interval containers templates  my implementation relies on the
existence of incrementation on the least available time unit in order
to decide things like
[1704, 4712) == [1704, 4711]

> I don't think incrementability is as simple as incrementing the
> private member of the date_time object.

The date and time implementations that I've seen so far are all based
on integral numeric types including boost::date_time. Implicit in this
implementation is the property of a least incrementable unit. Based on
this property incrementation and decrementation can always be
implemented. To me this seems to be a rather universal property and
not only detail of the implementing private member.

cheers Joachim